[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 07 Oct 2021 12:36:42 -0700
From: Keith Packard <keithp@...thp.com>
To: David Holland <dholland-libc@...bsd.org>, libc-coord@...ts.openwall.com
Subject: Re: freezero() and freezeroall()
David Holland <dholland-libc@...bsd.org> writes:
> I'm not sure I see the point of this function -- if you're calling
> explicit_bzero because you're handling secrets, skipping the bzero
> because the page is about to be unmapped seems like a mistake, so
> explicit_bzero followed by free seems just as good as anything and
> easier to reason about than adding something new.
Yeah, that's probably best practice for most cases as it also avoids
access to data from paths that don't use the current application page
table, and doesn't depend on the OS doing anything special.
However, if your threat model only covers access to the currently mapped
pages in the application, then skipping the bzero when the pages are
getting unmapped would be sufficient, and might offer significant
performance benefits.
> If you're not handling secrets, then it seems like security theater.
I can imagine an operating system which promises to clear anonymous
pages when unmapped, possibly using some OS-visible memory clearing
hardware. In that case, doing the explicit_bzero before unmapping the
pages would be unnecessary extra work.
Right now, that's quite unusual as the cost of clearing at free is
generally considerably higher than the cost of clearing at alloc, when
the application is likely to pull those cache lines in anyways, and
clearing may be able to avoid reading the lines from memory.
We just need to pick between these two options:
1. Clearing memory still visible to the application. Helpful for
use-after-free bugs, also helpful for in-application security
mitigation.
2. Clearing physical memory, even if it will no longer be visible to the
application. Helpful for all of the above, also helpful for
out-of-application security mitigation.
(I lean towards option 2. personally, as it offers the highest
mitigation potential)
--
-keith
Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
