Index | Thread | Search

From:
Claudio Jeker <cjeker@diehard.n-r-g.com>
Subject:
Re: patch: relax ni_pledge panic
To:
Theo de Raadt <deraadt@openbsd.org>, Mark Kettenis <mark.kettenis@xs4all.nl>, semarie@kapouay.eu.org, tech@openbsd.org
Date:
Fri, 7 Feb 2025 17:47:55 +0100

Download raw body.

Thread
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.

Since both pledge and unveil are almost never called it is better to
optimise for the readers (which happen on all or many syscalls).

-- 
:wq Claudio