Re: Fwd: explicit_bzero vs. alternatives
Philipp Klaus Krause wrote: > Am 11.08.20 um 02:48 schrieb Damien Miller: > > > > We went with explict_bzero because our only use-case for this was > > safe erasure that could not be elided by the compiler. > > > > I don't see any need for explicit_memset() - if anything depends on > > the overwritten value then simple memset() should be sufficient as > > the compiler should detect the dependency and refuse to elide the > > memset() to begin with. > > However, for an explicit_memset-like function, a good C implementation > would try to execute it as early as possible, while plain memset could > be moved to a later point in the program by optimizations. The goal is to to clear a transient object after last use, not ensure the transient space is filled with a specific value. Often times we need the object initialized also, I can assure you zeroes are always the correct value for initialization. A memset with a special value is no different than post-zeroing handling of the object. I have never seen a benefit to what you propose. > > Hopefully C2X is taking a more broad approach to this problem than > > considering new library calls. Over-eager optimisation (especially when > > done at link-time over the whole program) is a major for anyone trying > > to write safe C code. > > I don't think a broader approach could work. We need a broad approach to keep transport equipment not jumping off the rails or falling from the sky. It is likely people have or will eventually die as a result of C's hand-wavy reduction in accurate translation, and the continued justification of the error is astounding. Changing the rules of execution of pre-existing code and willfully dismissing and disclaiming all consequences is ethically wrong. > In general, the standard is > only concerned with state observable in the C abstract machine. > Everything else can only be hinted at (e.g. via volatile or something > like bzero/memset_explicit, etc). Again, wow. volatile was gutted by the standard and didn't work. bzero calls started being elided.
Re: Fwd: explicit_bzero vs. alternatives
Am 11.08.20 um 02:48 schrieb Damien Miller: > > We went with explict_bzero because our only use-case for this was > safe erasure that could not be elided by the compiler. > > I don't see any need for explicit_memset() - if anything depends on > the overwritten value then simple memset() should be sufficient as > the compiler should detect the dependency and refuse to elide the > memset() to begin with. However, for an explicit_memset-like function, a good C implementation would try to execute it as early as possible, while plain memset could be moved to a later point in the program by optimizations. > Hopefully C2X is taking a more broad approach to this problem than > considering new library calls. Over-eager optimisation (especially when > done at link-time over the whole program) is a major for anyone trying > to write safe C code. I don't think a broader approach could work. In general, the standard is only concerned with state observable in the C abstract machine. Everything else can only be hinted at (e.g. via volatile or something like bzero/memset_explicit, etc). Philipp
Re: Fwd: explicit_bzero vs. alternatives
On Mon, 10 Aug 2020, Amit Kulkarni wrote: > moving to tech@ > > -- Forwarded message - > From: Philipp Klaus Krause > Date: Mon, Aug 10, 2020 at 4:34 AM > Subject: explicit_bzero vs. alternatives > To: > > > OpenBSD has the explicit_bzero function to reliably (i.e. even if not > observable in the C abstract machine) overwrite memory with zeroes. > > WG14 is currently considering adding similar functionality to C2X. > > Considered options include: > > * A function like explicit_bzero or memset_explicit, that overwrites the > memory with a known value. > * A function like memclear, that overwrites the memory in an > implementation-defined manner, possibly using random data. > > Is there a rationale why OpenBSD went with their explicit_bzero design? > Were alternatives considered and rejected? We went with explict_bzero because our only use-case for this was safe erasure that could not be elided by the compiler. I don't see any need for explicit_memset() - if anything depends on the overwritten value then simple memset() should be sufficient as the compiler should detect the dependency and refuse to elide the memset() to begin with. Likewise, I can see no benefit for overwriting with random data. Doing this is always going to be more expensive and more likely to leak secrets, e.g. the length of cleared objects. Hopefully C2X is taking a more broad approach to this problem than considering new library calls. Over-eager optimisation (especially when done at link-time over the whole program) is a major for anyone trying to write safe C code. -d
Re: explicit_bzero vs. alternatives
> > > OpenBSD has the explicit_bzero function to reliably (i.e. even if not > observable in the C abstract machine) overwrite memory with zeroes. > WG14 is currently considering adding similar functionality to C2X. > > Considered options include: > > * A function like explicit_bzero or memset_explicit, that overwrites the > memory with a known value. > * A function like memclear, that overwrites the memory in an > implementation-defined manner, possibly using random data. > > Is there a rationale why OpenBSD went with their explicit_bzero design? > Were alternatives considered and rejected? > Well, from what I remember it was put there in order to combat the fact that compilers started to skip generating code for which they thought they knew the thinking behind the source, and that if you bzero() some area and don't read it you were not interested in the area and would not mind that the compiler skipped the bzero altogether for a nice speedup. Given the normal security stance of OpenBSD, not clearing out keys and passwords for a perceived "speed increase" was considered bad and stupid, and hence a function was created so that the compiler could not recognize the name "bzero" and silently take away the key/pw-clearing parts of the code. So, given that one would mainly use this to wipe a key/pw as soon as it is not used anymore AND that no later part of the code will be reading that buffer again (which is why it was optimized away), there would be little incentive to have memset_explicit to some other nonzero value which you would not read ever, nor to have random data there you also never read again. If your program did care about the contents after a call to any of these other *_explicit() versions then they would not be needed since the compiler would not remove the original bzero()/memset() to begin with. This, I would think, would be the reason for not having "fancy" versions of choose-what-byte-to-wipe-the-key-with functions. I don't see much of a threat in someone seeing my code writing zeros if they could snoop the bus during the cleaning, nor a RAM version of the old disk myth of can read 1-5-10 old versions of your data on a harddrive by reading slightly to the side of the track so you must overwrite with random data 10 times to cover your tracks. Perhaps I am not paranoid enough? -- May the most significant bit of your life be positive.
Fwd: explicit_bzero vs. alternatives
moving to tech@ -- Forwarded message - From: Philipp Klaus Krause Date: Mon, Aug 10, 2020 at 4:34 AM Subject: explicit_bzero vs. alternatives To: OpenBSD has the explicit_bzero function to reliably (i.e. even if not observable in the C abstract machine) overwrite memory with zeroes. WG14 is currently considering adding similar functionality to C2X. Considered options include: * A function like explicit_bzero or memset_explicit, that overwrites the memory with a known value. * A function like memclear, that overwrites the memory in an implementation-defined manner, possibly using random data. Is there a rationale why OpenBSD went with their explicit_bzero design? Were alternatives considered and rejected? Philipp
