[Cryptography] Making sure memory erasure is not optimized away
Phillip Hallam-Baker
phill at hallambaker.com
Sun Aug 28 22:36:48 EDT 2022
On Sun, Aug 28, 2022 at 5:21 PM Salz, Rich via cryptography <
cryptography at metzdowd.com> wrote:
> > I don't see how you're going to do any better than using qualifiers
> like "volatile" in C and C#.
>
> OpenSSL we had to drop into assembler in places where we could. Look up
> `OPENSSL_cleanse` The C function had to use an indirect call to prevent it
> being optimized away:
> typedef void *(*memset_t)(void *, int, size_t);
> static volatile memset_t memset_func = memset;
>
> void OPENSSL_cleanse(void *ptr, size_t len)
> {
> memset_func(ptr, 0, len);
> }
>
> > PS: Every operating system I know zeros storage before adding it to
> a process, so I'm kind of wondering what the threat model is here.
>
> Bugs within a program may allow an adversary to read memory that the
> program was expecting to be cleared.
>
Quite, and I don't trust the O/S not to give backdoor access. I can attach
a debugger to a running process, how does that work if not... ?
One thing that really worries me is that a lot of programs these days are
actually running in a Web browser in kiosk mode. And not a 1994 browser
with just good ol' HTML. No, they have JavaScript, Web Assembly and half a
billion lines of code along for the ride.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20220828/a0512a17/attachment.htm>
More information about the cryptography
mailing list