Ancestors

Written by comex on 2025-01-22 at 02:06

“Clang will now more aggressively use undefined behavior on pointer addition overflow for optimization purposes.” https://github.com/llvm/llvm-project/commit/c2979c58d49b

A whole lot of non-exploitable bugs may become exploitable pretty soon.

=> More informations about this toot | More toots from comex@mas.to

Written by gudenau on 2025-01-22 at 02:45

@comex This needs to be a warning at least. Also shout-out to clang optimizing crypto libraries to no longer be fixed time.

=> More informations about this toot | More toots from gudenau@fosstodon.org

Written by Marcus Müller on 2025-01-22 at 02:47

@gudenau @comex it has been a warning forever.

=> More informations about this toot | More toots from funkylab@mastodon.social

Written by Marcus Müller on 2025-01-22 at 02:49

@gudenau @comex and I'm not sure, but "I use a high level language whose model of the world explicitly says that execution duration is not an observable. My constant-time implementation isn't constant time" is the most "I'm infosec, I don't need to understand how things actually work" thing I keep on reading when it comes to complaining about compiler.

=> More informations about this toot | More toots from funkylab@mastodon.social

Toot

Written by gudenau on 2025-01-22 at 03:03

@funkylab @comex It was taking some math being done to avoid branches and optimizing it to use branches. It's kind of bad.

=> More informations about this toot | More toots from gudenau@fosstodon.org

Descendants

Written by Marcus Müller on 2025-01-22 at 03:07

@gudenau @comex no, that's the thing - if you need constant computation time, and are using C or C++, you're really simply using the wrong language. There's red tape all over the language specs that says "don't do that; the language only guarantees the result, not how you get there", explaining the execution & memory model, and people trying to be clever by finding some tricks the compiler doesn't yet know how to rewrite are simply gambling. Also, constant time is an extremely fragile claim

=> More informations about this toot | More toots from funkylab@mastodon.social

Written by Marcus Müller on 2025-01-22 at 03:11

@gudenau @comex … on computers built in the last 30 years. The same instructions take different time on the same hardware depending on the data - and what takes how much can then change with the next generation of microcode on the same CPU, or latest when switching to the next newer processor gen.

If your constant time implementation doesn't even deal with the C model of results only mattering, I'll be hard to convince that the conditional memory access instructions that CPUs have had for

=> More informations about this toot | More toots from funkylab@mastodon.social

Written by Marcus Müller on 2025-01-22 at 03:13

@gudenau @comex … decades now will not instantly leak information through timing.

Leave alone the question in which real world scenario you'd want a constant time algorithm rather than one in a secure enclave and a hardware-timer-enforced constant(or randomized) total run time, but I'm sure that exists in practice beyond the scope of software that I'm aware of.

=> More informations about this toot | More toots from funkylab@mastodon.social

Written by comex on 2025-01-24 at 19:11

@funkylab @gudenau Yes, if you are doing conditional memory accesses based on secret data then you're doing it wrong. But there are constant-time algorithms that don't do that. You still have to worry about non-constant-time math, but CPU vendors are starting to help, e.g. https://lwn.net/Articles/921511/

Yes, C is poorly suited for constant time algorithms, and there are newer languages like Jasmin and FaCT designed specifically for this ... but afaik they're rarely used in production.

=> More informations about this toot | More toots from comex@mas.to