lkml.org 
[lkml]   [2019]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v12 00/13] arm64: untag user pointers passed to the kernel
    On Tue, Mar 19, 2019 at 11:32:12AM -0700, Andrew Morton wrote:
    > On Mon, 18 Mar 2019 18:17:32 +0100 Andrey Konovalov <andreyknvl@google.com> wrote:
    > > === Notes
    > >
    > > This patchset is meant to be merged together with "arm64 relaxed ABI" [3].
    >
    > What does this mean, precisely? That neither series is useful without
    > the other? That either patchset will break things without the other?

    This series does the work of relaxing the ABI w.r.t. pointer syscall
    arguments for arm64 (while preserving backwards compatibility, we can't
    break this). Vincenzo's patches [1] document the ABI relaxation and
    introduce an AT_FLAG bit by which user space can check for the presence
    of such support. So I'd say [1] goes on top of this series.

    Once we agreed on the ABI definition, they should be posted as a single
    series.

    > Only a small fraction of these patches carry evidence of having been
    > reviewed. Fixable?

    That's fixable, though the discussions go back to last summer mostly at
    a higher level: are we sure these are the only places that need
    patching? The outcome of such discussions was a document clarifying
    which pointers user can tag and pass to the kernel based on the origins
    of the memory range (e.g. anonymous mmap()).

    I'd very much like to get input from the SPARC ADI guys on these series
    (cc'ing Khalid). While currently for arm64 that's just a software
    feature (the hardware one, MTE - memory tagging extensions, is coming
    later), the ADI has similar requirements regarding the user ABI. AFAICT
    from the SPARC example code, the user is not allowed to pass a tagged
    pointers (non-zero top byte) into the kernel. Feedback from the Google
    hwasan guys is that such approach is not practical for a generic
    deployment of this feature (e.g. automatic tagging of heap allocations).

    > Which maintainer tree would be appropriate for carrying these patches?

    Given that the arm64 changes are fairly minimal, the -mm tree works for
    me (once I reviewed/acked the patches and, ideally, get the SPARC people
    onboard with such approach).

    [1] https://lkml.org/lkml/2019/3/18/819

    --
    Catalin

    \
     
     \ /
      Last update: 2019-03-20 12:26    [W:4.444 / U:0.208 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site