--- Log opened Thu Jan 26 00:00:26 2023
00:01 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
00:40 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Read error: Connection reset by peer]
05:06 < real_or_random> BlueMatt[m]: we have https://github.com/bitcoin-core/secp256k1/issues/1138 to track this
06:40 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 246 seconds]
06:57 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
07:07 -!- halosghost [~halosghos@user/halosghost] has joined #secp256k1
08:28 < BlueMatt[m]> Ah, thanks
08:37 < sipa> I can't find much about this instruction yet.
08:51 < real_or_random> mh yeah, it would be nice to have the actual asm code
10:24 < sipa> Yeah, it's available in userspace.
10:25 < sipa> you need LDMXCSR to modify the flag, which exists in (as far as I can find) every x86 CPU.
10:25 < sipa> It's just a particular bit that may not be settable on CPUs that don't support it.
10:26 < sipa> Ah, no, it needs SSE.
10:26 < sipa> Which IIRC every x86_64 CPU has.
11:05 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
11:15 < BlueMatt[m]> right, sse itself is part of x86_64, so maybe just always set that bit on 64?
11:15 < BlueMatt[m]> and also arm if possible
11:16 < sipa> I don't think you can set the bit unless it's on an architecture known to support it.
11:16 < BlueMatt[m]> you can check for support tho
11:17 < sipa> I tried it on my Ryzen 5950X, and I don't get an error when I set the flag to that value, but it might in theory mean something completely unrelated.
11:17 < sipa> It's also not actually a bit, but a 16-bit mode value. You're supposed to store the old mode before entering ctime code, set it to a special constant-time mode value, and then restore the old mode when exiting.
11:18 < BlueMatt[m]> I'd think don't bother? maybe in a future cpu the performance penalty will be material, but until then who cares?
11:18 < sipa> Don't bother with what?
11:19 < BlueMatt[m]> storing + resetting
11:19 < BlueMatt[m]> "you're useing libsecp, you must be doing crypto, probably other crypto too, so here, we'll be overly helpful :)"
11:19 < sipa> Hmm, I just realize this needs OS support.
11:20 < sipa> Otherwise you may get scheduled on a different CPU/core a bit later, and not have your ctime mode travel with the process.
11:20 < BlueMatt[m]> oh? yuck.
11:20 < BlueMatt[m]> I'd imagine this would be applied by context switches in the future
11:20 < BlueMatt[m]> but, indeed, need to see how linux goes with it
11:21 < sipa> hmm, given that this register exists on all of x86_64 presumably any x86_64-compatible system already saves/stores them.
11:21 < sipa> https://www.felixcloutier.com/x86/ldmxcsr, FWIW
11:21 < BlueMatt[m]> well, hopefully? good to check tho yea
11:23 < sipa> oh wow this register is normally for rounding mode of vectorized float instructions
11:23 < sipa> pretty yuck that they're overloading it with something so unrelated, but i guess it means OS'es will automatically deal with storing/restoring it alrerady
11:24 < real_or_random> it think it will be very nasty not to reset this if we set it
11:24 < sipa> Yeah.
11:26 < sipa> It's not even a new bit in this register.
11:26 < sipa> Just a weird combination of flags that have existing meaning.
11:26 < sipa> But yeah, that most definitely means we need to store/restore it.
11:37 < real_or_random> I'm pretty sure the OS will handle a proper simulation for you
11:37 < real_or_random> I mean how should storing/restoring otherwise work at all given that processes can be interleaved
11:38 < sipa> Yeah that's what I meant: they probably picked an existing flag, using bits with existing semantics, to make sure existing operating systems will correctly save/restore the flags on context switching without even needing to be aware of it.
12:57 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 248 seconds]
13:01 -!- roconnor [~quassel@coq/roconnor] has quit [Ping timeout: 255 seconds]
14:07 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
14:18 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 255 seconds]
14:18 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1
14:19 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
14:22 -!- roconnor [~quassel@coq/roconnor] has joined #secp256k1
14:23 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 255 seconds]
14:31 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1
16:04 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
16:05 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1
16:54 -!- halosghost [~halosghos@user/halosghost] has quit [Quit: WeeChat 3.8]
20:11 -!- jon_atack [~jonatack@user/jonatack] has joined #secp256k1
20:14 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 260 seconds]
--- Log closed Fri Jan 27 00:00:26 2023