On 10/17/18 9:25 PM, Evgenii Stepanov wrote: > On Wed, Oct 17, 2018 at 7:20 AM, Andrey Konovalov <[email protected]> > wrote: >> On Wed, Oct 17, 2018 at 4:06 PM, Vincenzo Frascino >> <[email protected]> wrote: >>> Hi Andrey, >>> 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? >> >> Hi Vincenzo, >> >> 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 agree with both of you, ioctl is the real show stopper for this approach. Thanks for pointing this out. -- Regards, Vincenzo
