lkml.org 
[lkml]   [2020]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
    On Fri, Sep 18, 2020 at 3:44 PM Christoph Hellwig <hch@lst.de> wrote:
    >
    > On Fri, Sep 18, 2020 at 02:40:12PM +0100, Al Viro wrote:
    > > > /* Vector 0x110 is LINUX_32BIT_SYSCALL_TRAP */
    > > > - return pt_regs_trap_type(current_pt_regs()) == 0x110;
    > > > + return pt_regs_trap_type(current_pt_regs()) == 0x110 ||
    > > > + (current->flags & PF_FORCE_COMPAT);
    > >
    > > Can't say I like that approach ;-/ Reasoning about the behaviour is much
    > > harder when it's controlled like that - witness set_fs() shite...
    >
    > I don't particularly like it either. But do you have a better idea
    > how to deal with io_uring vs compat tasks?

    Do we need to worry about something other than the compat_iovec
    struct for now? Regarding the code in io_import_iovec(), it would
    seem that can easily be handled by exposing an internal helper.
    Instead of

    #ifdef CONFIG_COMPAT
    if (req->ctx->compat)
    return compat_import_iovec(rw, buf, sqe_len, UIO_FASTIOV,
    iovec, iter);
    #endif
    return import_iovec(rw, buf, sqe_len, UIO_FASTIOV, iovec, iter);

    This could do

    __import_iovec(rw, buf, sqe_len, UIO_FASTIOV, iovec,
    iter, req->ctx->compat);

    With the normal import_iovec() becoming a trivial wrapper around
    the same thing:

    ssize_t import_iovec(int type, const struct iovec __user * uvector,
    unsigned nr_segs, unsigned fast_segs,
    struct iovec **iov, struct iov_iter *i)
    {
    return __import_iovec(type, uvector, nr_segs, fast_segs, iov,
    i, in_compat_syscall());
    }


    Arnd

    \
     
     \ /
      Last update: 2020-09-18 15:59    [W:4.204 / U:0.216 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site