Sebastien Marie wrote:
> The diff switchs the function sc_mem_secure_alloc() to uses mmap(2) with
> MAP_CONCEAL as we do for secrets (it excludes this chunk of memory from core
> dumps), and to not uses mlock(2). And changes sc_mem_secure_free() too.
Why.
They tried to keep it out of swap, whic
On Wed, May 27, 2020 at 07:59:09AM +0200, Landry Breuil 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#L8
Landry Breuil 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
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 er
> 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 ke