4 ms·
There's absolutely nothing wrong with using memset. I don't understand why you would suggest such a ban. If your goal is to scrub a memory region after you're c
by halayli 5y ago
There's absolutely nothing wrong with using memset. I don't understand why you would suggest such a ban. If your goal is to scrub a memory region after you're completely done using it then you shouldn't use memset.
Compilers won't optimize out memset if it changes the program's behavior within the boundaries of abstract machine's specification.
A call to memset to clear a memory region after you're done with it because a password was stored there can be optimized out because it doesn't change the behavior of the program.
The code you shared is incorrect if your definition of correctness here includes K being wiped out.
- overgard 5y ago> A call to memset to clear a memory region after you're done with it because a password was stored there can be optimized out because it doesn't change the behavior of the program. Well, that does change the behavior of the program. After all, the behavior of the program was to wipe the memory. The programmer specified it. The compiler is clearly wrong by any reasonable measure. It's removing an intentional, clearly specified instruction. It's just wrong. It's making an "interpretation" of something the programmer intended as a fact, and breaking things in the process. Why does anyone think this is desirable? Any good programmer knows that correctness comes before speed. I've been programming C++ since 1998 and I didn't even know this till reading this thread. Blaming the user here is counterproductive. Compilers should not make this optimization, plain and simple. memset should set the memory. If you think otherwise, I invite you to take responsibility for all the users data you have placed in harms way.
- overgard 5y agoBtw to the downvoters, explain to me why a function that is clearly intended to create a side effect that is visible outside the process, IE something you cant reason about, is safe to remove? Memory debuggers are not new or exotic tech. Why do you think that is reasonable to remove if a programmer clearly thought it should be done?
- dagenix 5y ago> explain to me why a function that is clearly intended to create a side effect that is visible outside the process This is simply not accurate. memset_s provides that guarantee. memset does not. It would appear that you have been under the impression that it did. However, it did not.
- rurban 5y agoIt does not. Almost all memset_s implementations are broken, just mine not. memset_s just ensures that the unsane compiler will not optimize it away, whilst it should also ensure that is fenced. Otherwise you can still read the memory from the cache. Calling the ordinary memset_s secure is a bug, it's a mere convenience function.
- dagenix 5y agoI don't follow - how do memory fences make a meaningful difference in security?
- overgard 5y agoDoesn't it seem bad that the default that's been taught is wrong? Admittedly I haven't read a C programming book since 1998 because I've been coding that long, but, it strikes me as incredibly fucked that you need a separate memset_s to mean "I'm not fucking around". When I learned C, memset just meant, uh, set this memory, it was pretty straightforward.
- josephcsible 5y ago> the default that's been taught is wrong There's a big difference between you not liking something and it being wrong. You want to make the common case slower for everyone so that you don't have to learn one extra rule for your uncommon case. > it strikes me as incredibly fucked that you need a separate memset_s to mean "I'm not fucking around". When I learned C, memset just meant, uh, set this memory, it was pretty straightforward. I don't think it's ever worked the way you want it to work.