> Date: Thu, 2 Jul 2026 11:24:55 -0400 > From: Thor Lancelot Simon <[email protected]> > > On Wed, Jul 01, 2026 at 09:04:26PM +0200, Reinoud Zandijk wrote: > > > > I've tested it using read/write on /dev/drum and tested it for swapping on > > amd64 using plain and encrypted forms. One point of discussion could be that > > writing to /dev/drum from userland could be allowed or not. In the current > > patch its allowed. > > Both reading and writing on /dev/drum must be forbidden at securelevel > 0 > or the entire security model falls apart.
What security model falls apart? The threat model for swap encryption is generally access to the disk device later, because you've recycled your disk and some enterprising bitcoin wallet spelunker has bought it and is rifling through its contents. Before we added transparent swap encryption, uid 0 could still read /dev/drum or ptrace other uids' processes (except for pid 1). I think it would be reasonable to block those at securelevel 2. But reinoud's proposed change doesn't affect that one way or another. (Currently we don't even block reading from /dev/mem or /dev/kmem at securelevel>0 -- we only block writing to it. Maybe we should change that too.)
