Live data from Hacker News

Zeroing buffers is insufficient

daemonology.net

11–20 of 134 posts

Re: Zeroing buffers is insufficient

#11

I don't completely understand the C spec. Would the following approach work for zeroing a buffer? 1) Zero the buffer. 2) Check that the buffer is completely zeroed. 3) If you found any non-zeros in the buffer, return an error. Is the compiler still allowed to optimize away the zeroing in this case?

You are mixing up the C level buffer abstraction and some potentially underlying RAM. C doesn't deal with RAM, only with the abstraction, so you can't look at the RAM in C, you only can look at the abstract buffer, and the only thing that the compiler has to guarantee is that the abstraction holds - namely, that after you write zeroes into the abstract buffer, a subsequent conditional that checks whether the buffer is zeroed will branch accordingly, which is a fact that is trivial to evaluate during compile time, and as soon as the compiler has determined that the conditional is statically determined, it can eliminate any alternative branches as dead code and translate the abstract buffer write into a NOOP at the machine code level.

Re: Zeroing buffers is insufficient

#12
Remember this the next time someone says "C is basically portable assembler." It's not precisely because you can do many things in assembly that you can't directly do in c such as directly manipulate the stack and absolutely control storage locations.

Re: Zeroing buffers is insufficient

#13

Excellent point! I really hope such a sensible suggestion is added to mainstream compilers asap and blessed in future standards. Apologies to everyone suffering Mill fatigue, but we've tried to address this not at a language level but a machine level. As mitigation, we have a stack whose rubble you cannot browse, and no ... No registers! But the real strong security comes from the Mill's strong memory protection. It…

What's the current status of the Mill project? Is there a proof of concept compiler / emulator? What's the bootstrap strategy to get things rolling?

Re: Zeroing buffers is insufficient

#14

It's becoming gradually more tempting to write a crypto library in assembly language, because at least then, it says exactly what it's doing. Alas, microcode, and unreadability, and the difficulty of going from a provably correct kind of implementation all the way down to bare metal by hand. The proposed compiler extension, however, makes sense to me. Let's get it added to LLVM & GCC?

Another good reason to write crypto in assembly is to ensure that the implementation is not susceptible to timing attacks. If your code has different code paths that take different amounts of clock time attackers can use that. This can be difficult to achieve in a high level language.

Re: Zeroing buffers is insufficient

#15
post #7

"As with "anonymous" temporary space allocated on the stack, there is no way to sanitize the complete CPU register set from within portable C code" I don't know enough of modern hardware, but on CPUs with register renaming, is that even possible from assembly? I am thinking of the case where the CPU, instead of clearing register X in process P, renames another register to X and clears it. After that, program Q might…

Register renaming doesn't work like that. How could register contents of a process changing randomly even be usable for anything? Register renaming is about dynamically mapping a small number of ISA register names to a larger number of hardware registers to increase parallelism, but the whole reason for the exercise is that those additional registers don't have ISA names, so you obviously can't read them explicitly, at least not as part of the normal instruction set, who knows what backdoors some CPUs might have ...

Re: Zeroing buffers is insufficient

#16
The suggestion has the right idea, but the wrong implementation. The developer should be able to mark certain data as "secure" so the security of the data travels along the type system.

Botan, for example, has something called a "SecureVector" which I have never actually verified as being secure, but it's the same idea.

Re: Zeroing buffers is insufficient

#17
Why are there no suggestions to change processors accordingly? Intel should be considering changing the behavior of its encryption instructions to clear state when an operation is complete or at the request of software. Come to think of it, every CPU designer should be considering an instruction to clear the specified state (register set A, register set B) when requested by software. Then, the compiler can effectively support SECURE attributed variables, functions, or parameters without needing to stuff the pipleline with some kind of sanitizing code.

Re: Zeroing buffers is insufficient

#19
post #17

Why are there no suggestions to change processors accordingly? Intel should be considering changing the behavior of its encryption instructions to clear state when an operation is complete or at the request of software. Come to think of it, every CPU designer should be considering an instruction to clear the specified state (register set A, register set B) when requested by software. Then, the compiler can effectivel…

[deleted]

Re: Zeroing buffers is insufficient

#20
post #7

"As with "anonymous" temporary space allocated on the stack, there is no way to sanitize the complete CPU register set from within portable C code" I don't know enough of modern hardware, but on CPUs with register renaming, is that even possible from assembly? I am thinking of the case where the CPU, instead of clearing register X in process P, renames another register to X and clears it. After that, program Q might…

Register renaming is transparent (aside performance) even to assembly. Multi-core system are irrelevant as each core has the same set of registers and registers are not (visibly) shared amongst cores.
Post reply on HN