Landry Breuil <lan...@openbsd.org> wrote: > Maybe opensc upstream have valid reasons for calling mlock() or not, i'm > not in a position to judge that. > > Anyway, the corresponding code is probably there: > https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/sc.c#L895 > > Which was added 2 years ago in this PR, with subject 'Added memory > locking for secrets': https://github.com/OpenSC/OpenSC/pull/1491/files
Essentially, they are reserving physical memory to avoid the key going into swap. Of course, do do such a reservation, they require all regular programs in the system to be able to lock-down physical memory. Otherwise they would not be able to. That's clear right? They are doing this for a theorical "ooh someone stole my drive, and found a key" attack. Our swap is crypted. 20 years after we moved to crypted swap by default and 10 years after we removed support for non-crypted swap, almost every other operating system is moving to crypted swap as an option, and heading towards default. Even more relevant, the chances of memory ending up in swap is decreasing as machines have more physical memory. Or people are running in VMs, and mlock doesn't help this problem AT ALL because the underlying VM may put the memory anywhere it wants without caring, it's someone else's computer after all. Additionally, a study of the code suggests this memory is often accessed, so why would it ever be on the target list for pageout to swap? It won't be. They've chased a theoretical problem with a theoretical solution which Unix shouldn't have. The justification is incredibly weak. Their software probably contains other similar jumping-the-shark concepts, and I'm happy they are preventing our users from using it. As an OpenBSD developer, you should be able to judge things like this. You just need to be cynical and it falls into place quickly.
