Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 07 Oct 2021 12:36:42 -0700
From: Keith Packard <>
To: David Holland <>,
Subject: Re: freezero() and freezeroall()

David Holland <> 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

 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)


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.