[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