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.