Re: aio_read2() and aio_write2()

On Sun, Jan 14, 2024 at 10:13:43AM -0700, Alan Somers wrote:
> On Sun, Jan 14, 2024 at 10:07 AM Vinícius dos Santos Oliveira
> <vini.ipsmaker@gmail.com> wrote:
> >
> > Em dom., 14 de jan. de 2024 às 13:30, Alan Somers
> > <asomers@freebsd.org> escreveu:
> > > I don't understand.  What are you worried about that would block?
> > > lseek never does.  It never actually goes to disk; it just retrieves a
> > > variable from within the kernel.  So while the expense of a syscall is
> > > non-zero, you don't have to worry about lseek blocking.
> >
> > Sorry, that was a lot of condensed information that I dumped together.
> >
> > We can use lseek to get the offset and use AIO specifying the offset
> > we just queried. However the untrusted sandboxed process might
> > actually send as a socket file descriptor (we don't control what we
> > get from the untrusted sandboxed process), and lseek is then
> > inappropriate.
> 
> In that case, I believe lseek should return ESPIPE.
You need seek cap rights to do lseek(2) on fd, which are specifically
not included into cap rights needed for e.g. read(2) and write(2).

> 
> >From what I've read from the source code, we can pass
> > these bogus offsets to AIO, and it'll just work. However we're still
> > paying an extra syscall (and code doesn't feel right anyway).
> >
> > Anyway, the kernel *already* has this thread pool (AIO daemons), and
> > the only change required here is a flag that controls whether
> > FOF_OFFSET is passed along. That's a pretty non-invasive change. What
> > is the problem? Again, the model already works fine on Windows and
> > Linux.
> 
> The problem is that this flag would be almost impossible to use
> correctly for the intended use cases of POSIX AIO.  Your application
> is actually pretty unusual in that it only has one operation in-flight
> at a time.  I think it would be better to use the lseek solution
> rather than add a footgun to POSIX AIO.
> 
> -Alan