On Mon, Oct 10, 2022 at 11:34 AM David Laight <David.Laight@xxxxxxxxxx> wrote: > From: Paul Moore > > Sent: 10 October 2022 14:19 > .... > > > It isn't really ideal for the buffer pointer either. > > > That started as a single field (assuming the caller > > > has verified the user/kernel status), then the is_kernel > > > field was added for architectures where user/kernel > > > addresses use the same values. > > > Then a horrid bug (forgotten where) forced the is_kernel > > > field be used everywhere. > > > Again a structure with two pointers would be much safer. > > > > Any chance you have plans to work on this David? > > I'd only spend any significant time on it if there > is a reasonable chance of the patches being accepted. > > My use would be an out-of-tree non-GPL module calling > kernel_getsockopt(). > The main in-tree user is bpf - which seems to need an > ever-increasing number of socket options, but support has > been added one by one. > > While most getsockopt() calls just return set values, SCTP > uses some to retrieve the result of values negotiated with > the peer. The number of valid data streams is needed for > even trivial SCTP applications. > However I've a workaround for a bug in 5.1 to 5.8 that > returned the wrong values (my tests didn't check negotiation) > that also obtains the values on later kernels. > So I'm not (yet) in a hurry! It looks like it might still be a good idea to add hardening/support for the LSM hook as your needs still seem a bit far off, but I appreciate the background - thanks! -- paul-moore.com
