Index | Thread | Search

From:
"Theo de Raadt" <deraadt@openbsd.org>
Subject:
Re: SYS_pinsyscalls question
To:
Mark Kettenis <mark.kettenis@xs4all.nl>
Cc:
mjguzik@gmail.com, marc.espie.openbsd@gmail.com, tech@openbsd.org
Date:
Mon, 03 Mar 2025 08:24:14 -0700

Download raw body.

Thread
Mark Kettenis <mark.kettenis@xs4all.nl> wrote:

> > From: "Theo de Raadt" <deraadt@openbsd.org>
> > Date: Sun, 02 Mar 2025 16:35:51 -0700
> > 
> > > I think the worst case is when the thread sees the correct pn_end,
> > > pn_pins and pn_npins, but pn_start is still zero.  That could
> > > potentially permit a syscall that shouldn't be allowed.
> > 
> > No.
> > 
> >         if (plibcpin->pn_pins &&
> >             addr >= plibcpin->pn_start && addr < plibcpin->pn_end)
> >                 pin = plibcpin;
> > 
> > "addr" cannot be zero, because we don't allow mapping the NULL page
> > in userland.
> 
> That doesn't really matter for the scenario I have in mind.
> 
> What I'm talking about is the situation where a thread sees:
> 
>   pn_start = 0
>   pn_end != 0
>   pn_npins != 0
> 
> and addr < pn_end but also addr < intended value of pn_start.  In that
> scenario we'd pick the ps_libcpin table instead of the ps_pin table.
> And the ps_libcpin table might allow the syscall if:

What am I missing here?  The condition requires all all 3 of those to be
non-zero.  Since pn_start is still 0, it will not pick ps_libcpin.

This is not a matter of picking one pin table over another pin table.
It's hunting for the address.  The address can only be in one of them.