From: Martin Pieuchot Subject: Re: patch: relax ni_pledge panic To: Theo de Raadt , Mark Kettenis , semarie@kapouay.eu.org, tech@openbsd.org Date: Mon, 10 Feb 2025 12:32:52 +0100 On 07/02/25(Fri) 17:47, Claudio Jeker wrote: > On Thu, Feb 06, 2025 at 06:46:52PM +0100, Martin Pieuchot wrote: > > On 06/02/25(Thu) 09:43, Theo de Raadt wrote: > > > Mark Kettenis wrote: > > > > > > > > From: "Theo de Raadt" > > > > > Date: Thu, 06 Feb 2025 09:17:52 -0700 > > > > > > > > > > > [2] in another thread, pledge("stdio rpath wpath"), and returns. > > > > > > the process is now pledged. > > > > > > > > > > How can this be allowed? > > > > > > > > > > I am pretty sure sys_pledge should single-thread the process, which > > > > > means it will wait until other threads complete their in-kernel sleeps. > > > > > > > > I'm not sure clauio@ will agree with you ;) > > > > > > He just agreed with me privately. > > > > I'd rather see a rwlock be used to serialized access to the per-process > > data structures. I don't see any reason to use the single thread API > > for this and I'd rather not spread its usage. It is already a pain to > > work with. > > We need to fix that and this is what I'm slowly working at. The single > thread API should be simple and allow a few syscalls to know that no other > thread will disturb them. exec and exit are such cases but I think unveil > and pledge fall into a similar category. They alter the behaviour of the > process and should therefor change the sate in a safe fashion. I disagree with this approach. > Since both pledge and unveil are almost never called it is better to > optimise for the readers (which happen on all or many syscalls). Indeed, a read/write lock is fine.