linux-kernel - RE: [PATCHv13 05/16] x86/uaccess: Provide untagged_addr() and remove tags before address check

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: <4cf29f7a1a0041da818ac7ef598d142e@AcuMS.aculab.com>
Date:   Mon, 2 Jan 2023 13:55:05 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Linus Torvalds' <torvalds@...ux-foundation.org>,
        "Kirill A. Shutemov" <kirill@...temov.name>
CC:     "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>,
        "Peter Zijlstra" <peterz@...radead.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "Kostya Serebryany" <kcc@...gle.com>,
        Andrey Ryabinin <ryabinin.a.a@...il.com>,
        "Andrey Konovalov" <andreyknvl@...il.com>,
        Alexander Potapenko <glider@...gle.com>,
        Taras Madan <tarasmadan@...gle.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        "H . J . Lu" <hjl.tools@...il.com>,
        Andi Kleen <ak@...ux.intel.com>,
        "Rick Edgecombe" <rick.p.edgecombe@...el.com>,
        Bharata B Rao <bharata@....com>,
        Jacob Pan <jacob.jun.pan@...ux.intel.com>,
        Ashok Raj <ashok.raj@...el.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCHv13 05/16] x86/uaccess: Provide untagged_addr() and remove
 tags before address check

From: Linus Torvalds
> Sent: 31 December 2022 00:42
> 
...
> And on 64-bit, we really only need to check the high bit.
> 
> In fact, we don't even want to *check* it, because then we need to do
> that disgusting array_index_mask_nospec thing to mask the bits for it,
> so it would be even better to use purely arithmetic with no
> conditionals anywhere.
> 
> And that's exactly what we could do on x86-64:
> 
>         movq %rdx,%rax
>         shrq $63,%rax
>         orq %rax,%rdx
> 
> would actually be noticeably better than what we do now for for
> TASK_SIZE checking _and_ for the array index masking (for putuser.S,
> we'd use %rbx instead of %rax in that sequence).
...
> It would just turn all kernel addresses into all ones, which is then
> guaranteed to fault. So no need for any conditional that never
> triggers in real life anyway.

Are byte loads guaranteed to fault?
I suspect the 'all ones' address can be assigned to io.
So get/put_user for a byte probably needs a 'js' test after the 'orq'.
(I don't think you need to worry about a apeculative load from an
uncached address.)

...
> And once we don't test against TASK_SIZE, the need for UNTAG_ADDR just
> goes away, so now LAM is better too.
> 
> In other words, we could actually improve on our current code _and_
> simplify the LAM situation. Win-win.

Presumably the fault handler already has the code to untag addresses.

It has to be said that I don't really see why tagging addresses is a
significant benefit unless the hardware checks than the PTE/TLB is
also set with the correct tag.
All it seems to me that it does it make more 'random addresses' valid.

Clearly interpreters can set and check the high address bits, but they
can also mask them after the checks (or use xor to flip the bits and
let the cpu fault on errors).

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)