--- Log opened Tue May 19 00:00:25 2020 00:37 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-ekbwjdyjnyhvfhjb] has quit [Ping timeout: 240 seconds] 00:59 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-knrypoqzrmwzpbov] has joined #secp256k1 10:39 -!- AprilFruit [ab0fac82@gateway/web/cgi-irc/kiwiirc.com/ip.171.15.172.130] has joined #secp256k1 10:45 -!- AprilFruit [ab0fac82@gateway/web/cgi-irc/kiwiirc.com/ip.171.15.172.130] has quit [Quit: Connection closed] 11:02 < real_or_random> sipa: it's not that clear that this is UB. on types without trap representations (and uintXX_t never has trap representations), and r has its address taken, so I think this is not UB. but whatever, there is not much point in these discussions. even if it's not UB, "(r->d[0] & mask0) | (a->d[0] & mask1)" is indeterminate, so the cmov does not do what it is supposed to do 11:03 < real_or_random> elichai2: ^^ 11:03 < real_or_random> elichai2: (if you're not working on this) can you open an issue? feel free to just paste the log. 11:04 < sipa> real_or_random: where do you read that uintXX_t never has trap representations? 11:09 < real_or_random> it can't because it must be XX bits wide and be able to represent 2^32 values 11:09 < real_or_random> so all bits are value bits 11:13 < sipa> real_or_random: that makes sense 11:14 < elichai2> A. I think there's no such thing as "trap representation" in C89, B. I think uninit reads are UB regardless? 11:21 -!- afk11` [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection] 11:22 -!- afk11` [~afk11@gateway/tor-sasl/afk11] has joined #secp256k1 11:25 < real_or_random> yeah okay, I mean C89 is just underdefined ^^ but see https://github.com/bitcoin-core/secp256k1/pull/699#issuecomment-569413087 11:25 < real_or_random> I guess it's better so simply avoid these weird cases 11:25 < real_or_random> also because compilers are rather brittle in those corner cases (even if we the language lawyer turns out to be right) 11:26 < real_or_random> and the C committee apparently can't agree whether it's UB to read unit data 11:35 < elichai2> I wouldn't be suprised if memcpy is a special case though 11:36 < elichai2> do you think default initializing is a good enough solution? I wrote here hoping someone will come up with a more clever idea :) 11:36 < elichai2> gmaxwell really doesn't like default init :P 11:36 < sipa> every data type can be accessed by its by representation (so you can cast to (un)signed char* and dereference) 11:37 < elichai2> sipa: you mean dereferencing uninit type as a unsigned char? 11:39 < real_or_random> what are the drawbacks of default initializing? 11:40 < elichai2> 1. some negligible perf impact. 2. removing the use of valgrind/mSan as a way to check logic errors (although they quite disappointed me here) 11:40 < elichai2> *the ability 11:41 < real_or_random> well yes unsigned char is also guaranteed to have no trap representation... (in C versions where a trap repr. exists but I think every sane compiler fills the underdefined stuff in C89 with later versions) 11:41 < real_or_random> why 2? 11:42 < elichai2> because lets say I accidentally removed a write into the variable, valgrind will detect it if there's any condition on that variable, but if we default init it then it won't detect anything 11:43 < elichai2> https://github.com/bitcoin/bitcoin/pull/17627#issuecomment-559525797 :) 11:44 < real_or_random> oh I remember this 11:45 < real_or_random> can we write a better cmov that does not read the value? 11:45 < sipa> real_or_random: that sounds like a contradiction 11:46 < sipa> if the cmov does not read the values it is not using, it's by definition not constant time (its memory access pattern will depend on the secret input) 11:47 < elichai2> we could write an ASM one. that way we don't need to care about C rules I believe 11:51 < real_or_random> sipa: this seems right 11:51 < sipa> elichai2: i like just treating uintXX_t as not having trap values, and thereby not being UB, only unspecified 11:52 < sipa> C89 doesn't have a concept of trap values, but it also doesn't have uintXX_t 11:53 < real_or_random> the issue is that then cmov may not do what its supposed to do 11:53 < sipa> how so? 11:53 < sipa> unspecified & 0 = 0 11:53 < real_or_random> no! 11:53 < sipa> no? 11:53 < real_or_random> unspecified & 0 = unspecified 11:53 < sipa> no 11:53 < real_or_random> yes :D 11:54 < sipa> unspecified just means any valid uint32_t, you just don't know which one 11:54 < sipa> for any such value, & 0 gives 0 11:55 < real_or_random> no, let me look up the reference 11:55 < sipa> "indeterminate" is the term from the spec, i think 12:02 < real_or_random> http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_451.htm 12:02 < real_or_random> " The answer to question 1 is "yes", an uninitialized value under the conditions described can appear to change its value. " 12:03 < elichai2> https://godbolt.org/z/u5rL-k :) but that's not with `& 0x00` 12:03 < sipa> that's not in contradiction with "x & 0" being 0 12:03 < sipa> it just means that printf("%i %i", x, x); may print two different values 12:03 < elichai2> "Specifically, "unstable" values will also propagate through function calls. Also, after x[0] *= 0;" 12:04 < sipa> ah. 12:04 < elichai2> "the value of x[0] still will be "unstable" and hence still can be any byte, and will not necessary be 0." 12:06 < real_or_random> and LLVM really makes use of this. it's intermediate representation has values like "undef" 12:06 < real_or_random> ok yes I quoted the wrong sentence 12:07 < elichai2> yeah in llvm IR you can literally mark values as undef, and then people fight if undef should be per value or per bit :) 12:07 < real_or_random> also this one "In the case of an indeterminate value all bit-patterns are valid representations and the actual bit-pattern may change without direct action of the program." from http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm for C99 12:08 < real_or_random> well again the wrong sentence, whatever 12:45 < elichai2> found another instance of this :\ 12:46 < elichai2> here: https://github.com/bitcoin-core/secp256k1/blob/master/src/ecmult_const_impl.h#L31 we have clearing above but only under VERIFY and here we pass it uninit value: https://github.com/bitcoin-core/secp256k1/blob/master/src/ecmult_const_impl.h#L186 12:51 < elichai2> What if I added `VALGRIND_CHECK_MEM_IS_DEFINED` there?(ifdef VALGRIND) altough that also has overhead, could've added it under VERIFY but then it wouldn't have cough the ecmult one here 12:57 < elichai2> What's even the point of `VERIFY_SETUP`? it was added 5 years ago by andytoshi here: https://github.com/bitcoin-core/secp256k1/pull/252 13:00 < sipa> hmm, it's something like VERIFY_CHECK, but disabled during coverage analysis 13:01 < elichai2> and I assume the point is to reset the magnitude+normalized because it might be uninit 13:26 < elichai2> real_or_random: opened an issue, feel free to comment there. when the solutions/mitigations are clear I don't mind opening a PR https://github.com/bitcoin-core/secp256k1/issues/753 14:02 < real_or_random> ok thanks, let's discuss there then 14:16 -!- roconnor [~roconnor@host-45-78-197-156.dyn.295.ca] has quit [Quit: Konversation terminated!] 16:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection] 16:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 20:46 -!- afk11` [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 240 seconds] 20:49 -!- afk11` [~afk11@gateway/tor-sasl/afk11] has joined #secp256k1 --- Log closed Wed May 20 00:00:26 2020