lkml.org 
[lkml]   [2020]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [PATCH 32/33] sctp: add sctp_sock_get_primary_addr
    Date
    From: David Laight
    > Sent: 14 May 2020 13:30
    > Subject: RE: [PATCH 32/33] sctp: add sctp_sock_get_primary_addr
    >
    > From: David Laight
    > > Sent: 14 May 2020 10:51
    > > From: Marcelo Ricardo Leitner
    > > > Sent: 13 May 2020 19:03
    > > >
    > > > On Wed, May 13, 2020 at 08:26:47AM +0200, Christoph Hellwig wrote:
    > > > > Add a helper to directly get the SCTP_PRIMARY_ADDR sockopt from kernel
    > > > > space without going through a fake uaccess.
    > > >
    > > > Same comment as on the other dlm/sctp patch.
    > >
    > > Wouldn't it be best to write sctp_[gs]etsockotp() that
    > > use a kernel buffer and then implement the user-space
    > > calls using a wrapper that does the copies to an on-stack
    > > (or malloced if big) buffer.
    >
    > Actually looking at __sys_setsockopt() it calls
    > BPF_CGROUP_RUN_PROG_SETSOCKOPT() which (by the look of it)
    > can copy the user buffer into malloc()ed memory and
    > cause set_fs(KERNEL_DS) be called.
    >
    > The only way to get rid of that set_fs() is to always
    > have the buffer in kernel memory when the underlying
    > setsockopt() code is called.

    And having started to try coding __sys_setsockopt()
    and then found the compat code I suspect that would
    be a whole lot more sane if the buffer was in kernel
    and it knew that at least (say) 64 bytes were allocated.

    The whole compat_alloc_user_space() 'crap' could probably go.

    Actually it looks like an application can avoid whatever
    checks BPF_CGROUP_RUN_PROG_SETSOCKOPT() is trying to do
    by using the 32bit compat ioctls.

    David

    -
    Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
    Registration No: 1397386 (Wales)

    \
     
     \ /
      Last update: 2020-05-14 15:28    [W:3.797 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site