lkml.org 
[lkml]   [2015]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 26/26] x86, pkeys: Documentation

    * Andy Lutomirski <luto@amacapital.net> wrote:

    > >> Assuming it boots up fine on a typical distro, i.e. assuming that there are no
    > >> surprises where PROT_READ && PROT_EXEC sections are accessed as data.
    > >
    > > I can't wait to find out what implicitly expects PROT_READ from
    > > PROT_EXEC mappings. :)

    So what seems to happen is that there are no pure PROT_EXEC mappings in practice -
    they are only omnibus PROT_READ|PROT_EXEC mappings, an unknown proportion of which
    truly relies on PROT_READ:

    $ for C in firefox ls perf libreoffice google-chrome Xorg xterm \
    konsole; do echo; echo "# $C:"; strace -e trace=mmap -f $C -h 2>&1 | cut -d, -f3 | \
    grep PROT | sort | uniq -c; done

    # firefox:
    13 PROT_READ
    82 PROT_READ|PROT_EXEC
    184 PROT_READ|PROT_WRITE
    2 PROT_READ|PROT_WRITE|PROT_EXEC

    # ls:
    2 PROT_READ
    7 PROT_READ|PROT_EXEC
    17 PROT_READ|PROT_WRITE

    # perf:
    1 PROT_READ
    20 PROT_READ|PROT_EXEC
    44 PROT_READ|PROT_WRITE

    # libreoffice:
    2 PROT_NONE
    87 PROT_READ
    148 PROT_READ|PROT_EXEC
    339 PROT_READ|PROT_WRITE

    # google-chrome:
    39 PROT_READ
    121 PROT_READ|PROT_EXEC
    345 PROT_READ|PROT_WRITE

    # Xorg:
    1 PROT_READ
    22 PROT_READ|PROT_EXEC
    39 PROT_READ|PROT_WRITE

    # xterm:
    1 PROT_READ
    25 PROT_READ|PROT_EXEC
    46 PROT_READ|PROT_WRITE

    # konsole:
    1 PROT_READ
    101 PROT_READ|PROT_EXEC
    175 PROT_READ|PROT_WRITE

    So whatever kernel side method we come up with, it's not something that I expect
    to become production quality. "Proper" conversion to pkeys has to be driven from
    the user-space side.

    That does not mean we can not try! :-)

    > There's one annoying issue at least:
    >
    > mprotect_pkey(..., PROT_READ | PROT_EXEC, 0) sets protection key 0.
    > mprotect_pkey(..., PROT_EXEC, 0) maybe sets protection key 15 or
    > whatever we use for this. What does mprotect_pkey(..., PROT_EXEC, 0)
    > do? What if the caller actually wants key 0? What if some CPU vendor
    > some day implements --x for real?

    That comes from the hardcoded "user-space has 4 bits to itself, not managed by the
    kernel" assumption in the whole design. So no layering between different
    user-space libraries using pkeys in a different fashion, no transparent kernel use
    of pkeys (such as it may be), etc.

    I'm not sure it's _worth_ managing these 4 bits, but '16 separate keys' does seem
    to be to me above a certain resource threshold that should be more explicitly
    managed than telling user-space: "it's all yours!".

    > Also, how do we do mprotect_pkey and say "don't change the key"?

    So if we start managing keys as a resource (i.e. alloc/free up to 16 of them), and
    provide APIs for user-space to do all that, then user-space is not supposed to
    touch keys it has not allocated for itself - just like it's not supposed to write
    to fds it has not opened.

    Such an allocation method can still 'mess up', and if the kernel allocates a key
    for its purposes it should not assume that user-space cannot change it, but at
    least for non-buggy code there's no interaction and it would work out fine.

    Thanks,

    Ingo


    \
     
     \ /
      Last update: 2015-10-02 08:41    [W:2.675 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site