On Tue, May 26, 2020 at 08:58:16AM -0600, Theo de Raadt wrote: > > firefox[50499]: pledge "", syscall 203 > > This is mlock. > > It is not suitable in a privsep + pledge program. > > pledge challenges programs to be narrower and more careful in their > system call use for two reasons: upon error they can cause less damage > within the filesystem, and upon control fewer kernel subsystems can be > reached causing even more grave problems. > > My position is that a *user program* should not exclusively reserve a > physical resource, as physical resources are supposed to be *shared* > > This probably comes out of a library. The concept is: pull a library > written by who knows who, surely full of leaky abstractions and a weak > implimentation of the rules of behaviour, into a monster program. > > And hope for a good outcome. > > In the greater open source community, every large program and library > must use every shiny system call, because that large program is surely > the only program running, and when it is running, it is the most > important piece of software in the universe. When you are a pig > resource sharing is a stupid idea, right? > > mlock(0, ~0); > > Maybe ls and cat should use mlock? Maybe ksh. How about we just call > mlock inside malloc? > > I've gone so far as to consider making mlock() as non-root be a NOP, > simply return 0. > > There is a disease in this source code development industry.
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 And fwiw, i recently had exchanges with someone else trying to use an estonian id card, so it seems this usecase is 'common'. Maybe fixing/looking at opensc is the way to go. Landry
