On Wed, Oct 17, 2018 at 01:25:42PM -0700, Evgenii Stepanov wrote: > On Wed, Oct 17, 2018 at 7:20 AM, Andrey Konovalov <andreyknvl@xxxxxxxxxx> wrote: > > On Wed, Oct 17, 2018 at 4:06 PM, Vincenzo Frascino > > <vincenzo.frascino@xxxxxxx> wrote: > >> I have been thinking a bit lately on how to address the problem of > >> user tagged pointers passed to the kernel through syscalls, and > >> IMHO probably the best way we have to catch them all and make sure > >> that the approach is maintainable in the long term is to introduce > >> shims that tag/untag the pointers passed to the kernel. > >> > >> In details, what I am proposing can live either in userspace > >> (preferred solution so that we do not have to relax the ABI) or in > >> kernel space and can be summarized as follows: > >> - A shim is specific to a syscall and is called by the libc when > >> it needs to invoke the respective syscall. > >> - It is required only if the syscall accepts pointers. > >> - It saves the tags of a pointers passed to the syscall in memory > >> (same approach if the we are passing a struct that contains > >> pointers to the kernel, with the difference that all the tags of > >> the pointers in the struct need to be saved singularly) > >> - Untags the pointers > >> - Invokes the syscall > >> - Retags the pointers with the tags stored in memory > >> - Returns > >> > >> What do you think? > > > > If I correctly understand what you are proposing, I'm not sure if that > > would work with the countless number of different ioctl calls. For > > example when an ioctl accepts a struct with a bunch of pointer fields. > > In this case a shim like the one you propose can't live in userspace, > > since libc doesn't know about the interface of all ioctls, so it can't > > know which fields to untag. The kernel knows about those interfaces > > (since the kernel implements them), but then we would need a custom > > shim for each ioctl variation, which doesn't seem practical. > > The current patchset handles majority of pointers in a just a few > common places, like copy_from_user. Userspace shims will need to untag > & retag all pointer arguments - we are looking at hundreds if not > thousands of shims. They will also be located in a different code base > from the syscall / ioctl implementations, which would make them > impossible to keep up to date. I think ioctls are a good reason not to attempt such user-space shim layer (though it would have been much easier for the kernel ;)). -- Catalin
