On Wed, May 11, 2022 at 05:27:40AM +0300, Kirill A. Shutemov wrote:
> Hi all. Here's long overdue update on LAM enabling.
>
> # Description #
>
> Linear Address Masking[1] (LAM) modifies the checking that is applied to
> 64-bit linear addresses, allowing software to use of the untranslated
> address bits for metadata.
>
> The patchset brings support for LAM for userspace addresses.
>
> The most sensitive part of enabling is change in tlb.c, where CR3 flags
> get set. Please take a look that what I'm doing makes sense.
>
> 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?
Any such program simply *cannot* run on 5 level pagetables. Why do we
want to do this?
On Wed, May 11 2022 at 08:49, Peter Zijlstra wrote:
> On Wed, May 11, 2022 at 05:27:40AM +0300, Kirill A. Shutemov wrote:
>> Hi all. Here's long overdue update on LAM enabling.
>>
>> # Description #
>>
>> Linear Address Masking[1] (LAM) modifies the checking that is applied to
>> 64-bit linear addresses, allowing software to use of the untranslated
>> address bits for metadata.
>>
>> The patchset brings support for LAM for userspace addresses.
>>
>> The most sensitive part of enabling is change in tlb.c, where CR3 flags
>> get set. Please take a look that what I'm doing makes sense.
>>
>> 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?
>
> Any such program simply *cannot* run on 5 level pagetables. Why do we
> want to do this?
More bits are better :)
Seriously, I agree that restricting it to LAM57, which gives us 6 bits,
makes a lot of sense _and_ makes the whole thing way simpler.
So supporting both needs a truly good justification and a real world use
case.
Thanks,
tglx
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.
On Thu, May 12, 2022 at 05:42:58PM +0200, Thomas Gleixner wrote:
> On Wed, May 11 2022 at 08:49, Peter Zijlstra wrote:
> > On Wed, May 11, 2022 at 05:27:40AM +0300, Kirill A. Shutemov wrote:
> >> Hi all. Here's long overdue update on LAM enabling.
> >>
> >> # Description #
> >>
> >> Linear Address Masking[1] (LAM) modifies the checking that is applied to
> >> 64-bit linear addresses, allowing software to use of the untranslated
> >> address bits for metadata.
> >>
> >> The patchset brings support for LAM for userspace addresses.
> >>
> >> The most sensitive part of enabling is change in tlb.c, where CR3 flags
> >> get set. Please take a look that what I'm doing makes sense.
> >>
> >> 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?
> >
> > Any such program simply *cannot* run on 5 level pagetables. Why do we
> > want to do this?
>
> More bits are better :)
>
> Seriously, I agree that restricting it to LAM57, which gives us 6 bits,
> makes a lot of sense _and_ makes the whole thing way simpler.
>
> So supporting both needs a truly good justification and a real world use
> case.
I asked the question before[1]. Basically, more bits more better:
For HWASAN #bits == detection probability.
For MarkUS #bits == exponential cost reduction
I would really like to have only LAM_U57, but IIUC 6 bits is not always
enough.
Dmitry, could you elaborate?
[1] https://mobile.twitter.com/dvyukov/status/1342019823400837120
--
Kirill A. Shutemov