[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200529191207.GH429721@cisco>
Date: Fri, 29 May 2020 13:12:07 -0600
From: Tycho Andersen <tycho@...ho.ws>
To: Sargun Dhillon <sargun@...gun.me>
Cc: Kees Cook <keescook@...omium.org>, christian.brauner@...ntu.com,
containers@...ts.linux-foundation.org, cyphar@...har.com,
jannh@...gle.com, jeffv@...gle.com, linux-api@...r.kernel.org,
linux-kernel@...r.kernel.org, palmer@...gle.com, rsesek@...gle.com,
Matt Denton <mpdenton@...gle.com>
Subject: Re: [PATCH v2 3/3] selftests/seccomp: Test SECCOMP_IOCTL_NOTIF_ADDFD
On Fri, May 29, 2020 at 06:46:07PM +0000, Sargun Dhillon wrote:
> On Fri, May 29, 2020 at 12:41:51AM -0700, Kees Cook wrote:
> > On Thu, May 28, 2020 at 04:08:58AM -0700, Sargun Dhillon wrote:
> > > + EXPECT_EQ(ioctl(listener, SECCOMP_IOCTL_NOTIF_SEND, &resp), 0);
> > > +
> > > + nextid = req.id + 1;
> > > +
> > > + /* Wait for getppid to be called for the second time */
> > > + sleep(1);
> >
> > I always rebel at finding "sleep" in tests. ;) Is this needed? IIUC,
> > userspace will immediately see EINPROGRESS after the NOTIF_SEND
> > finishes, yes?
> >
> > Otherwise, yes, this looks good.
> >
> > --
> > Kees Cook
> I'm open to better suggestions, but there's a race where if getppid
> is not called before the second SECCOMP_IOCTL_NOTIF_ADDFD is called,
> you will just get an ENOENT, since the notification ID is not found.
Ah, I see. The goal is to test the -EINPROGRESS here.
If you use write() instead of getppid(), and write to a socket, will
that work? The parent can block for the read, and once some thing has
been read it can test for -EINPROGRESS.
The user_notification_signal test does something similar.
Tycho
Powered by blists - more mailing lists