Thread (67 messages) 67 messages, 11 authors, 2020-09-23

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

From: Arnd Bergmann <arnd@arndb.de>
Date: 2020-09-20 13:56:22
Also in: io-uring, keyrings, linux-arch, linux-arm-kernel, linux-block, linux-fsdevel, linux-mm, linux-s390, linux-scsi, linux-security-module, linuxppc-dev, lkml, netdev, sparclinux

On Sun, Sep 20, 2020 at 12:09 AM Al Viro [off-list ref] wrote:
On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote:
quoted
On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
quoted
Said that, why not provide a variant that would take an explicit
"is it compat" argument and use it there?  And have the normal
one pass in_compat_syscall() to that...
That would help to not introduce a regression with this series yes.
But it wouldn't fix existing bugs when io_uring is used to access
read or write methods that use in_compat_syscall().  One example that
I recently ran into is drivers/scsi/sg.c.
So screw such read/write methods - don't use them with io_uring.
That, BTW, is one of the reasons I'm sceptical about burying the
decisions deep into the callchain - we don't _want_ different
data layouts on read/write depending upon the 32bit vs. 64bit
caller, let alone the pointer-chasing garbage that is /dev/sg.
Would it be too late to limit what kind of file descriptors we allow
io_uring to read/write on?

If io_uring can get changed to return -EINVAL on trying to
read/write something other than S_IFREG file descriptors,
that particular problem space gets a lot simpler, but this
is of course only possible if nobody actually relies on it yet.

      Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help