| Message ID | 20200813153254.93731-1-sgarzare@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | io_uring: add restrictions to support untrusted applications and guests | expand |
Hi Jens, this is a gentle ping. I'll respin, using memdup_user() for restriction registration. I'd like to get some feedback to see if I should change anything else. Do you think it's in good shape? Thanks, Stefano On Thu, Aug 13, 2020 at 5:34 PM Stefano Garzarella <sgarzare@redhat.com> wrote: > > v4: > - rebased on top of io_uring-5.9 > - fixed io_uring_enter() exit path when ring is disabled > > v3: https://lore.kernel.org/io-uring/20200728160101.48554-1-sgarzare@redhat.c= > om/ > RFC v2: https://lore.kernel.org/io-uring/20200716124833.93667-1-sgarzare@redh= > at.com > RFC v1: https://lore.kernel.org/io-uring/20200710141945.129329-1-sgarzare@red= > hat.com > > Following the proposal that I send about restrictions [1], I wrote this series > to add restrictions in io_uring. > > I also wrote helpers in liburing and a test case (test/register-restrictions.= > c) > available in this repository: > https://github.com/stefano-garzarella/liburing (branch: io_uring_restrictions) > > Just to recap the proposal, the idea is to add some restrictions to the > operations (sqe opcode and flags, register opcode) to safely allow untrusted > applications or guests to use io_uring queues. > > The first patch changes io_uring_register(2) opcodes into an enumeration to > keep track of the last opcode available. > > The second patch adds IOURING_REGISTER_RESTRICTIONS opcode and the code to > handle restrictions. > > The third patch adds IORING_SETUP_R_DISABLED flag to start the rings disabled, > allowing the user to register restrictions, buffers, files, before to start > processing SQEs. > > Comments and suggestions are very welcome. > > Thank you in advance, > Stefano > > [1] https://lore.kernel.org/io-uring/20200609142406.upuwpfmgqjeji4lc@steredha= > t/ > > Stefano Garzarella (3): > io_uring: use an enumeration for io_uring_register(2) opcodes > io_uring: add IOURING_REGISTER_RESTRICTIONS opcode > io_uring: allow disabling rings during the creation > > fs/io_uring.c | 160 ++++++++++++++++++++++++++++++++-- > include/uapi/linux/io_uring.h | 60 ++++++++++--- > 2 files changed, 203 insertions(+), 17 deletions(-) > > --=20 > 2.26.2 >
On 8/25/20 9:20 AM, Stefano Garzarella wrote: > Hi Jens, > this is a gentle ping. > > I'll respin, using memdup_user() for restriction registration. > I'd like to get some feedback to see if I should change anything else. > > Do you think it's in good shape? As far as I'm concerned, this is fine. But I want to make sure that Kees is happy with it, as he's the one that's been making noise on this front.
On Wed, Aug 26, 2020 at 10:47:36AM -0600, Jens Axboe wrote: > On 8/25/20 9:20 AM, Stefano Garzarella wrote: > > Hi Jens, > > this is a gentle ping. > > > > I'll respin, using memdup_user() for restriction registration. > > I'd like to get some feedback to see if I should change anything else. > > > > Do you think it's in good shape? > > As far as I'm concerned, this is fine. But I want to make sure that Kees > is happy with it, as he's the one that's been making noise on this front. Oop! Sorry, I didn't realize this was blocked on me. Once I saw how orthogonal io_uring was to "regular" process trees, I figured this series didn't need seccomp input. (I mean, I am still concerned about attack surface reduction, but that seems like a hard problem given io_uring's design -- it is, however, totally covered by the LSMs, so I'm satisfied from that perspective.) I'll go review... thanks for the poke. :)
On Wed, Aug 26, 2020 at 12:40:24PM -0700, Kees Cook wrote: > On Wed, Aug 26, 2020 at 10:47:36AM -0600, Jens Axboe wrote: > > On 8/25/20 9:20 AM, Stefano Garzarella wrote: > > > Hi Jens, > > > this is a gentle ping. > > > > > > I'll respin, using memdup_user() for restriction registration. > > > I'd like to get some feedback to see if I should change anything else. > > > > > > Do you think it's in good shape? > > > > As far as I'm concerned, this is fine. But I want to make sure that Kees > > is happy with it, as he's the one that's been making noise on this front. > > Oop! Sorry, I didn't realize this was blocked on me. Once I saw how > orthogonal io_uring was to "regular" process trees, I figured this > series didn't need seccomp input. (I mean, I am still concerned about > attack surface reduction, but that seems like a hard problem given > io_uring's design -- it is, however, totally covered by the LSMs, so I'm > satisfied from that perspective.) > > I'll go review... thanks for the poke. :) > Jens, Kees, thanks for your feedbacks! I'll send v5 adding the values to the enumerations. Stefano