linux-kernel - Re: [RFCv2 00/10] Linear Address Masking enabling

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: <20bada85-9203-57f4-2502-57a6fd11f3ea@intel.com>
Date:   Thu, 12 May 2022 10:22:47 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Peter Zijlstra <peterz@...radead.org>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc:     Dave Hansen <dave.hansen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>, x86@...nel.org,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Alexander Potapenko <glider@...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>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [RFCv2 00/10] Linear Address Masking enabling

On 5/10/22 23:49, Peter Zijlstra wrote:
>> The feature competes for bits with 5-level paging: LAM_U48 makes it
>> impossible to map anything about 47-bits. The patchset made these
>> capability mutually exclusive: whatever used first wins. LAM_U57 can be
>> combined with mappings above 47-bits.
> So aren't we creating a problem with LAM_U48 where programs relying on
> it are of limited sustainability?

I think allowing apps to say, "It's LAM_U48 or bust!" is a mistake.
It's OK for a debugging build that runs on one kind of hardware.  But,
if we want LAM-using binaries to be portable, we have to do something
different.

One of the stated reasons for adding LAM hardware is that folks want to
use sanitizers outside of debugging environments.  To me, that means
that LAM is something that the same binary might run with or without.

It's totally fine with me if the kernel only initially supports LAM_U57.
 But, I'd ideally like to make sure that the ABI can support LAM_U57,
LAM_U48, AMD's UAI (in whatever form it settles), or other masks.