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.

Reply via email to