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 <mark.kettenis@xs4all.nl> wrote:
> > > 
> > > > > From: "Theo de Raadt" <deraadt@openbsd.org>
> > > > > 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.