Why wouldn't you make key volatile? Shouldn't that solve all the problems? Or is it because it would be to slow because the compiler can't do that many optimizations in the rest of the function any more?
How to zero a buffer
31–40 of 216 posts
Re: How to zero a buffer
#32This sort of thing would be exactly what should go into the "Friendly C" dialect being chatted about the other day--for things like zeroing memory, it's very unexpected that a compiler would be like "nah, not feeling it...nobody will notice anyways".
If you're not worried about writing in a language which is widely supported, just use memset_s and tell people to find a C11 compiler.
[deleted]
Re: How to zero a buffer
#33Slightly OT since it has little to do with security, but fighting the optimizer is something FPGA Verilog and VHDL designers must also master.
If you don't use an the result of some logic it will be optimized out. One way to prevent this is to route it to a pin.
If logic is fed by a constant, it will be optimized out right up to the point where the result of the logic is mixed with some external input. (early tools could not use the dedicated reset net due to this- reset for each flip-flop had to be routed to a pin or the reset net was optimized out which means the initial state of your flip-flop is lost).
If you have identical logic, one copy is optimized out due to aggressive CSE. This is often bad for performance (routing in an FPGA is as slow as logic, so it's better to regenerate identical results in multiple places), so you add "syn_maxfan" constraints to prevent the "optimization".
On the other hand, an input flip flop will be duplicated if the fanout limit is exceeded- but this prevents the use of the dedicated I/O cell flip flop which then causes external timing to be messed up. So you use syn_maxfan=infinite for this case.
Re: How to zero a buffer
#34This sort of thing would be exactly what should go into the "Friendly C" dialect being chatted about the other day--for things like zeroing memory, it's very unexpected that a compiler would be like "nah, not feeling it...nobody will notice anyways".
If you're not worried about writing in a language which is widely supported, just use memset_s and tell people to find a C11 compiler.
memset_s is an optional feature of C11. Implementations are not required to provide it unless they define __STDC_LIB_EXT1__.
Re: How to zero a buffer
#35Why wouldn't you make key volatile? Shouldn't that solve all the problems? Or is it because it would be to slow because the compiler can't do that many optimizations in the rest of the function any more?
Yes, making key volatile would force the zeroing to happen; and yes, you don't want to do that because it would absolutely kill your code performance.
Re: How to zero a buffer
#36Why would the compiler be allowed optimize away a call to a perfectly valid function? This seems like it's allowing to compiler to make judgement calls on whether or not your code is worthy of being executed.
There's a lot of dead code in real programs, and this kind of optimization gets rid of a lot of it.
...especially for code that's macro heavy. It's easy to have code where a macro is including a memset to protect some invariant. The compiler can see the bigger picture and realizes that the memset target isn't actually read from again in this case.
Re: How to zero a buffer
#37Earlier quoted context omitted.
Colin, if you don't me asking (and this is extremely off topic), do you know of any resources to read up on the differences between FreeBSD and DragonflyBSD now 11 years after the split. I'm not looking for you to take sides on the matter. I just enjoy reading history and would like to read a recent review of the two BSD now 11 years later and how they compare. I've looked and looked for the past few months and can't…
DragonflyBSD is less mature. This allows them to play around with things in ways which we can't do in FreeBSD because we don't want to break production systems. In many ways DragonflyBSD acts as a skunkworks for FreeBSD -- we import a lot of cool stuff from there, once it has been proven to work. On the other hand, I wouldn't want to run DragonflyBSD in production... because skunkworks projects often don't work.
Do you happen to have anything written on comparing modern FreeBSD with Linux (either kernel vs kernel or FreeBSD vs say Debian)?
Re: How to zero a buffer
#38Earlier quoted context omitted.
humble attitude I'm guessing you haven't seen the "comeback of all time" thread...
I haven't. But I think it's super funny and cool that you (yourself) are pointing it out. All the best with you. Edit: just read the "comeback of all time". That was really funny. Nice nod from PG as well. For those of you unaware like me: https://news.ycombinator.com/item?id=35083 Colin is our resident mathematical genius :)
Thanks for linking that. It's always interesting to see posts from several years ago and reflect on how things turned out (if you go up a few parents you can see discussion about tarsnap and dropbox makes a brief appearance).
Re: How to zero a buffer
#39Earlier quoted context omitted.
DragonflyBSD is less mature. This allows them to play around with things in ways which we can't do in FreeBSD because we don't want to break production systems. In many ways DragonflyBSD acts as a skunkworks for FreeBSD -- we import a lot of cool stuff from there, once it has been proven to work. On the other hand, I wouldn't want to run DragonflyBSD in production... because skunkworks projects often don't work.
Do you happen to have anything written on comparing modern FreeBSD with Linux (either kernel vs kernel or FreeBSD vs say Debian)?
No, but the major differences I find are:
1. The FreeBSD base system is developed intact, so there are far fewer kernel/library versioning issues.
2. FreeBSD, possibly because of its academic heritage, tends to take a more careful "let's study this problem and make sure we come up with the right solution" approach. This means that FreeBSD development is often slower, but once a feature is added it is more likely to actually work. (This is somewhat self-reinforcing: FreeBSD's stability attracts companies building servers and appliances, and when those companies contribute back they care a lot about having things continue to not break.)
3. Linux is far more popular, especially on desktops, so it tends to get drivers for new hardware faster (especially for consumer hardware).
4. FreeBSD is BSD licensed, which makes it available for a lot of companies which wouldn't want to get anywhere near Linux.
Re: How to zero a buffer
#40Earlier quoted context omitted.
Do you happen to have anything written on comparing modern FreeBSD with Linux (either kernel vs kernel or FreeBSD vs say Debian)?
No, but the major differences I find are: 1. The FreeBSD base system is developed intact, so there are far fewer kernel/library versioning issues. 2. FreeBSD, possibly because of its academic heritage, tends to take a more careful "let's study this problem and make sure we come up with the right solution" approach. This means that FreeBSD development is often slower, but once a feature is added it is more likely to a…
Thanks. That fits my general idea of FreeBSD. I've mostly wondered about how they technically compare though. Facebook seems to think Linux is generally faster for example[1]. I'd love to follow this more closely but I haven't found a LWN equivalent for the BSDs.