linux-kernel - Re: [PATCH v7 7/8] arm64: update Documentation/arm64/tagged-pointers.txt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181018173135.GF237391@arrakis.emea.arm.com>
Date:   Thu, 18 Oct 2018 18:31:36 +0100
From:   Catalin Marinas <catalin.marinas@....com>
To:     Andrey Konovalov <andreyknvl@...gle.com>
Cc:     Mark Rutland <mark.rutland@....com>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Will Deacon <will.deacon@....com>,
        Kostya Serebryany <kcc@...gle.com>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>,
        Chintan Pandya <cpandya@...eaurora.org>,
        Shuah Khan <shuah@...nel.org>, Ingo Molnar <mingo@...nel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Jacob Bramley <Jacob.Bramley@....com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Evgeniy Stepanov <eugenis@...gle.com>,
        Kees Cook <keescook@...omium.org>,
        Ruben Ayrapetyan <Ruben.Ayrapetyan@....com>,
        Ramana Radhakrishnan <Ramana.Radhakrishnan@....com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Memory Management List <linux-mm@...ck.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
        Lee Smith <Lee.Smith@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Robin Murphy <robin.murphy@....com>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>
Subject: Re: [PATCH v7 7/8] arm64: update
 Documentation/arm64/tagged-pointers.txt

On Wed, Oct 10, 2018 at 04:09:25PM +0200, Andrey Konovalov wrote:
> On Wed, Oct 3, 2018 at 7:32 PM, Catalin Marinas <catalin.marinas@....com> wrote:
> > On Tue, Oct 02, 2018 at 03:12:42PM +0200, Andrey Konovalov wrote:
[...]
> > Also, how is user space supposed to know that it can now pass tagged
> > pointers into the kernel? An ABI change (or relaxation), needs to be
> > advertised by the kernel, usually via a new HWCAP bit (e.g. HWCAP_TBI).
> > Once we have a HWCAP bit in place, we need to be pretty clear about
> > which syscalls can and cannot cope with tagged pointers. The "as of now"
> > implies potential further relaxation which, again, would need to be
> > advertised to user in some (additional) way.
> 
> How exactly should I do that? Something like this [1]? Or is it only
> for hardware specific things and for this patchset I need to do
> something else?
> 
> [1] https://github.com/torvalds/linux/commit/7206dc93a58fb76421c4411eefa3c003337bcb2d

Thinking some more on this, we should probably keep the HWCAP_* bits for
actual hardware features. Maybe someone else has a better idea (the
linux-abi list?). An option would be to make use of AT_FLAGS auxv
(currently 0) in Linux. I've seen some MIPS patches in the past but
nothing upstream.

Yet another option would be for the user to probe on some innocuous
syscall currently returning -EFAULT on tagged pointer arguments but I
don't particularly like this.

> >> - - pointer arguments to system calls, including pointers in structures
> >> -   passed to system calls,
> >> +  - pointer arguments (including pointers in structures), which don't
> >> +    describe virtual memory ranges, passed to system calls
> >
> > I think we need to be more precise here...
> 
> In what way?

In the way of being explicit about which syscalls support tagged
pointers, unless we find a good reason to support tagged pointers on all
syscalls and avoid any lists.

-- 
Catalin