From: "Theo de Raadt" To: Caspar Schutijser , Landry Breuil , ports@openbsd.org Mail-Followup-To: Caspar Schutijser , Landry Breuil , ports@openbsd.org Subject: Re: firefox: pledge violation through pkcs11/smart card usage Comments: In-reply-to Stuart Henderson message dated "Sun, 22 May 2022 18:44:51 +0100." Date: Sun, 22 May 2022 11:54:42 -0600 Sender: owner-ports@openbsd.org Stuart Henderson wrote: > On 2022/05/22 08:58, Theo de Raadt wrote: > > The existing code uses mlock. It appears to be using mlock for a > > privacy reason. But mlock has no privacy reason. > > The mlock page does not make any privacy or security promises at all. > > OpenSC is used on Linux too, mlock there does give some guarantees: > > mlock(), mlock2(), and mlockall() lock part or all of the calling > process's virtual address space into RAM, preventing that memory > from being paged to the swap area. > > ... > > Memory locking has two main applications: real-time algorithms > and high-security data processing. Real-time applications > require deterministic timing, and, like scheduling, paging is one > major cause of unexpected program execution delays. Real-time > applications will usually also switch to a real-time scheduler > with sched_setscheduler(2). Cryptographic security software > often handles critical bytes like passwords or secret keys as > data structures. As a result of paging, these secrets could be > transferred onto a persistent swap store medium, where they might > be accessible to the enemy long after the security software has > erased the secrets in RAM and terminated. (But be aware that the > suspend mode on laptops and some desktop computers will save a > copy of the system's RAM to disk, regardless of memory locks.) POSIX has this to say on the matter: https://pubs.opengroup.org/onlinepubs/009696699/functions/mlock.html None of what Linux is doing here is in the spec, and I would argue it isn't even in the spirit of what mlock was for ("performance"). So maybe just #ifdef __linux__ that block, and submit back to upstream. I really think replacing this with calloc_conceal(3) is junk science. > > This library is used in a gigantic program which does a ton of other > > memory allocations, which uses a huge number of other libraries which > > do a ton of other memory allocations. Is it used in libcrypto? No. > It's used in smaller programs too. Like OpenSSH. openssh does not use mlock. We really never know when a 'secret' is going to be put into memory, because noone built for that model of strict object handling. And since openssh to a large degree uses libcrypto, it means there are 'un-mlocked secrets there also'. Even the bignum library used by asn1 doesn't do this. In some classes of software, it is keys at the bottom, and secrets above. It is junk science to secrecy-lock the keys without secrecy-locking the user's data, as the purpose of the keys is to provide a variety of security gaurantees to the various kinds of data. For this library, used in this application, to suddenly want this requirement fulfilled in such a narrow scope, is completely pointless. Maybe malloc -- and mmap for that matter -- should mlock all memory, just in case the user of that memory should be better protected than careful process memory management? In an abundance of caution of course, why show any concern for the downsides and consequences. /sarcasm.