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.
LAM_U48 enabling is controversial since it competes for bits with
5-level paging. Its enabling isolated into an optional last patch that
can be applied at maintainer's discretion.
Please review and consider applying.
v5:
- Do not use switch_mm() in enable_lam_func()
- Use mb()/READ_ONCE() pair on LAM enabling;
- Add self-test by Weihong Zhang;
- Add comments;
v4:
- Fix untagged_addr() for LAM_U48;
- Remove no-threads restriction on LAM enabling;
- Fix mm_struct access from /proc/$PID/arch_status
- Fix LAM handling in initialize_tlbstate_and_flush()
- Pack tlb_state better;
- Comments and commit messages;
v3:
- Rebased onto v5.19-rc1
- Per-process enabling;
- API overhaul (again);
- Avoid branches and costly computations in the fast path;
- LAM_U48 is in optional patch.
v2:
- Rebased onto v5.18-rc1
- New arch_prctl(2)-based API
- Expose status of LAM (or other thread features) in
/proc/$PID/arch_status
[1] ISE, Chapter 10. https://cdrdv2.intel.com/v1/dl/getContent/671368
Kirill A. Shutemov (8):
x86/mm: Fix CR3_ADDR_MASK
x86: CPUID and CR3/CR4 flags for Linear Address Masking
mm: Pass down mm_struct to untagged_addr()
x86/mm: Handle LAM on context switch
x86/uaccess: Provide untagged_addr() and remove tags before address
check
x86/mm: Provide ARCH_GET_UNTAG_MASK and ARCH_ENABLE_TAGGED_ADDR
x86: Expose untagging mask in /proc/$PID/arch_status
x86/mm: Extend LAM to support to LAM_U48
Weihong Zhang (5):
selftests/x86/lam: Add malloc test cases for linear-address masking
selftests/x86/lam: Add mmap and SYSCALL test cases for linear-address
masking
selftests/x86/lam: Add io_uring test cases for linear-address masking
selftests/x86/lam: Add inherit test cases for linear-address masking
selftests/x86/lam: Add tests cases for LAM_U48
arch/arm64/include/asm/memory.h | 4 +-
arch/arm64/include/asm/signal.h | 2 +-
arch/arm64/include/asm/uaccess.h | 4 +-
arch/arm64/kernel/hw_breakpoint.c | 2 +-
arch/arm64/kernel/traps.c | 4 +-
arch/arm64/mm/fault.c | 10 +-
arch/sparc/include/asm/pgtable_64.h | 2 +-
arch/sparc/include/asm/uaccess_64.h | 2 +
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/elf.h | 3 +-
arch/x86/include/asm/mmu.h | 6 +
arch/x86/include/asm/mmu_context.h | 58 ++
arch/x86/include/asm/processor-flags.h | 2 +-
arch/x86/include/asm/tlbflush.h | 36 +
arch/x86/include/asm/uaccess.h | 42 +-
arch/x86/include/uapi/asm/prctl.h | 3 +
arch/x86/include/uapi/asm/processor-flags.h | 6 +
arch/x86/kernel/Makefile | 2 +
arch/x86/kernel/fpu/xstate.c | 47 -
arch/x86/kernel/proc.c | 60 ++
arch/x86/kernel/process.c | 3 +
arch/x86/kernel/process_64.c | 83 +-
arch/x86/kernel/sys_x86_64.c | 5 +-
arch/x86/mm/hugetlbpage.c | 6 +-
arch/x86/mm/mmap.c | 10 +-
arch/x86/mm/tlb.c | 42 +-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
drivers/infiniband/hw/mlx4/mr.c | 2 +-
drivers/media/common/videobuf2/frame_vector.c | 2 +-
drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +-
.../staging/media/atomisp/pci/hmm/hmm_bo.c | 2 +-
drivers/tee/tee_shm.c | 2 +-
drivers/vfio/vfio_iommu_type1.c | 2 +-
fs/proc/task_mmu.c | 2 +-
include/linux/mm.h | 11 -
include/linux/uaccess.h | 15 +
lib/strncpy_from_user.c | 2 +-
lib/strnlen_user.c | 2 +-
mm/gup.c | 6 +-
mm/madvise.c | 2 +-
mm/mempolicy.c | 6 +-
mm/migrate.c | 2 +-
mm/mincore.c | 2 +-
mm/mlock.c | 4 +-
mm/mmap.c | 2 +-
mm/mprotect.c | 2 +-
mm/mremap.c | 2 +-
mm/msync.c | 2 +-
tools/testing/selftests/x86/Makefile | 2 +-
tools/testing/selftests/x86/lam.c | 913 ++++++++++++++++++
virt/kvm/kvm_main.c | 2 +-
53 files changed, 1315 insertions(+), 127 deletions(-)
create mode 100644 arch/x86/kernel/proc.c
create mode 100644 tools/testing/selftests/x86/lam.c
--
2.35.1
On Wed, Jul 13, 2022 at 1:13 AM Kirill A. Shutemov
<[email protected]> wrote:
>
> 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.
>
> LAM_U48 enabling is controversial since it competes for bits with
> 5-level paging. Its enabling isolated into an optional last patch that
> can be applied at maintainer's discretion.
I believe having optional patches will put unnecessary burden on
distro maintainers.
Soon after landing U48 support other changes will start piling on top
of it, and it will be impossible to maintain a kernel with this patch
removed.
It also won't make any difference for the upstream, where this patch
will be always present.
We'd better decide now whether we need U48 or not, and either keep it
or delete it.
On Mon, Jul 18, 2022 at 07:39:22PM +0200, Alexander Potapenko wrote:
> On Wed, Jul 13, 2022 at 1:13 AM Kirill A. Shutemov
> <[email protected]> wrote:
> >
> > 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.
> >
> > LAM_U48 enabling is controversial since it competes for bits with
> > 5-level paging. Its enabling isolated into an optional last patch that
> > can be applied at maintainer's discretion.
>
> I believe having optional patches will put unnecessary burden on
> distro maintainers.
> Soon after landing U48 support other changes will start piling on top
> of it, and it will be impossible to maintain a kernel with this patch
> removed.
> It also won't make any difference for the upstream, where this patch
> will be always present.
>
> We'd better decide now whether we need U48 or not, and either keep it
> or delete it.
Dave, Andy, any position on this?
I wrote LAM_U48 support to prove that interface is flexible enough, but I
see why it can be a problem if a distro will pick them up ahead of
upstream.
--
Kirill A. Shutemov
On Wed, Jul 20, 2022 at 2:59 AM Kirill A. Shutemov
<[email protected]> wrote:
>
> On Mon, Jul 18, 2022 at 07:39:22PM +0200, Alexander Potapenko wrote:
> > On Wed, Jul 13, 2022 at 1:13 AM Kirill A. Shutemov
> > <[email protected]> wrote:
> > >
> > > 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.
For what it's worth, there's an LLVM bot running basic HWASan tests on
QEMU with the latest LAM patches here:
https://lab.llvm.org/buildbot/#/builders/169
So far the bot is happy, giving us some sense of LAM_U57 support being sane.
I'll add some tags to individual patches.
On 7/19/22 17:59, Kirill A. Shutemov wrote:
> Dave, Andy, any position on this?
>
> I wrote LAM_U48 support to prove that interface is flexible enough, but I
> see why it can be a problem if a distro will pick them up ahead of
> upstream.
My position is that maintaining distro forks is troublesome. If you
held a gun to my head today and made me merge *something* I'd leave out
the U48 patch, but reserve the right to add it later.
I'm not sure whether that makes the distros lives easier or harder. I'm
not promising anything either way, though.