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)
