| Message ID | 20210205151631.43511-1-kirill.shutemov@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Linear Address Masking enabling | expand |
On Fri, Feb 05, 2021 at 06:16:20PM +0300, Kirill A. Shutemov 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. And I suppose we still can't switch between 4 and 5 level at runtime, using a CR3 bit?
On Fri, Feb 05, 2021 at 04:49:05PM +0100, Peter Zijlstra wrote: > On Fri, Feb 05, 2021 at 06:16:20PM +0300, Kirill A. Shutemov 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. > > And I suppose we still can't switch between 4 and 5 level at runtime, > using a CR3 bit? No. And I can't imagine how would it work with 5-level on kernel side.
On Fri, Feb 05, 2021 at 07:01:27PM +0300, Kirill A. Shutemov wrote: > On Fri, Feb 05, 2021 at 04:49:05PM +0100, Peter Zijlstra wrote: > > On Fri, Feb 05, 2021 at 06:16:20PM +0300, Kirill A. Shutemov 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. > > > > And I suppose we still can't switch between 4 and 5 level at runtime, > > using a CR3 bit? > > No. And I can't imagine how would it work with 5-level on kernel side. KPTI already switches CR3 on every entry and only maps a very limited number of kernel pages in the user map. This means a 4 level user page-table should be possible. The kernel page-tables would only need to update their p5d[0] on every 4l user change. Not as nice as actually having separate user and kernel page-tables in hardware, but it would actually make 5l page-tables useful on machines with less than stupid amounds of memory I think. One of the road-blocks to doing per-cpu kernel page-tables is having to do 2k copies, only having to update a single P5D entry would be ideal. Ofcourse, once we get 5l user tables we're back to being stupid, but maybe tasks with that much memory don't actually switch much, who knows.
On Fri, Feb 5, 2021 at 4:16 PM Kirill A. Shutemov <kirill.shutemov@linux.intel.com> 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. > > 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 patchset is RFC quality and the code requires more testing before it > can be applied. > > The userspace API is not finalized yet. The patchset extends API used by > ARM64: PR_GET/SET_TAGGED_ADDR_CTRL. The API is adjusted to not imply ARM > TBI: it now allows to request a number of bits of metadata needed and > report where these bits are located in the address. > > There's an alternative proposal[2] for the API based on Intel CET > interface. Please let us know if you prefer one over another. > > 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. > > I include QEMU patch in case if somebody wants to play with the feature. Exciting! Do you plan to send the QEMU patch to QEMU? > The branch: > > git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git lam > > Any comments are welcome. > > [1] ISE, Chapter 14. https://software.intel.com/content/dam/develop/external/us/en/documents-tps/architecture-instruction-set-extensions-programming-reference.pdf > [2] https://github.com/hjl-tools/linux/commit/e85fa032e5b276ddf17edd056f92f599db9e8369 > > Kirill A. Shutemov (9): > mm, arm64: Update PR_SET/GET_TAGGED_ADDR_CTRL interface > x86/mm: Fix CR3_ADDR_MASK > x86: CPUID and CR3/CR4 flags for Linear Address Masking > x86/mm: Introduce TIF_LAM_U57 and TIF_LAM_U48 > x86/mm: Provide untagged_addr() helper > x86/uaccess: Remove tags from the address before checking > x86/mm: Handle tagged memory accesses from kernel threads > x86/mm: Make LAM_U48 and mappings above 47-bits mutually exclusive > x86/mm: Implement PR_SET/GET_TAGGED_ADDR_CTRL with LAM > > arch/arm64/include/asm/processor.h | 12 +- > arch/arm64/kernel/process.c | 45 +++++- > arch/arm64/kernel/ptrace.c | 4 +- > arch/x86/include/asm/cpufeatures.h | 1 + > arch/x86/include/asm/elf.h | 3 +- > arch/x86/include/asm/mmu.h | 1 + > arch/x86/include/asm/mmu_context.h | 13 ++ > arch/x86/include/asm/page_32.h | 3 + > arch/x86/include/asm/page_64.h | 19 +++ > arch/x86/include/asm/processor-flags.h | 2 +- > arch/x86/include/asm/processor.h | 10 ++ > arch/x86/include/asm/thread_info.h | 9 +- > arch/x86/include/asm/tlbflush.h | 5 + > arch/x86/include/asm/uaccess.h | 16 +- > arch/x86/include/uapi/asm/processor-flags.h | 6 + > arch/x86/kernel/process_64.c | 145 ++++++++++++++++++ > arch/x86/kernel/sys_x86_64.c | 5 +- > arch/x86/mm/hugetlbpage.c | 6 +- > arch/x86/mm/mmap.c | 9 +- > arch/x86/mm/tlb.c | 124 +++++++++++++-- > kernel/sys.c | 14 +- > .../testing/selftests/arm64/tags/tags_test.c | 31 ---- > .../selftests/{arm64 => vm}/tags/.gitignore | 0 > .../selftests/{arm64 => vm}/tags/Makefile | 0 > .../{arm64 => vm}/tags/run_tags_test.sh | 0 > tools/testing/selftests/vm/tags/tags_test.c | 57 +++++++ > 26 files changed, 464 insertions(+), 76 deletions(-) > delete mode 100644 tools/testing/selftests/arm64/tags/tags_test.c > rename tools/testing/selftests/{arm64 => vm}/tags/.gitignore (100%) > rename tools/testing/selftests/{arm64 => vm}/tags/Makefile (100%) > rename tools/testing/selftests/{arm64 => vm}/tags/run_tags_test.sh (100%) > create mode 100644 tools/testing/selftests/vm/tags/tags_test.c > > -- > 2.26.2 >
On Sun, Feb 07, 2021 at 09:24:23AM +0100, Dmitry Vyukov wrote: > On Fri, Feb 5, 2021 at 4:16 PM Kirill A. Shutemov > <kirill.shutemov@linux.intel.com> 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. > > > > 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 patchset is RFC quality and the code requires more testing before it > > can be applied. > > > > The userspace API is not finalized yet. The patchset extends API used by > > ARM64: PR_GET/SET_TAGGED_ADDR_CTRL. The API is adjusted to not imply ARM > > TBI: it now allows to request a number of bits of metadata needed and > > report where these bits are located in the address. > > > > There's an alternative proposal[2] for the API based on Intel CET > > interface. Please let us know if you prefer one over another. > > > > 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. > > > > I include QEMU patch in case if somebody wants to play with the feature. > > Exciting! Do you plan to send the QEMU patch to QEMU? Sure. After more testing, once I'm sure it's conforming to the hardware.
On Sun, 7 Feb 2021 at 15:11, Kirill A. Shutemov <kirill@shutemov.name> wrote: > > On Sun, Feb 07, 2021 at 09:24:23AM +0100, Dmitry Vyukov wrote: > > On Fri, Feb 5, 2021 at 4:16 PM Kirill A. Shutemov > > <kirill.shutemov@linux.intel.com> 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. > > > > > > 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 patchset is RFC quality and the code requires more testing before it > > > can be applied. > > > > > > The userspace API is not finalized yet. The patchset extends API used by > > > ARM64: PR_GET/SET_TAGGED_ADDR_CTRL. The API is adjusted to not imply ARM > > > TBI: it now allows to request a number of bits of metadata needed and > > > report where these bits are located in the address. > > > > > > There's an alternative proposal[2] for the API based on Intel CET > > > interface. Please let us know if you prefer one over another. > > > > > > 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. > > > > > > I include QEMU patch in case if somebody wants to play with the feature. > > > > Exciting! Do you plan to send the QEMU patch to QEMU? > > Sure. After more testing, once I'm sure it's conforming to the hardware. A follow up after H.J.'s LPC talk: https://linuxplumbersconf.org/event/11/contributions/1010/ (also +Carlos) As far as I understood, this kernel series depends on the Intel CET patches. Where are these compiler-rt patches that block gcc support?
On Tue, Sep 21, 2021 at 9:52 AM Dmitry Vyukov <dvyukov@google.com> wrote: > > On Sun, 7 Feb 2021 at 15:11, Kirill A. Shutemov <kirill@shutemov.name> wrote: > > > > On Sun, Feb 07, 2021 at 09:24:23AM +0100, Dmitry Vyukov wrote: > > > On Fri, Feb 5, 2021 at 4:16 PM Kirill A. Shutemov > > > <kirill.shutemov@linux.intel.com> 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. > > > > > > > > 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 patchset is RFC quality and the code requires more testing before it > > > > can be applied. > > > > > > > > The userspace API is not finalized yet. The patchset extends API used by > > > > ARM64: PR_GET/SET_TAGGED_ADDR_CTRL. The API is adjusted to not imply ARM > > > > TBI: it now allows to request a number of bits of metadata needed and > > > > report where these bits are located in the address. > > > > > > > > There's an alternative proposal[2] for the API based on Intel CET > > > > interface. Please let us know if you prefer one over another. > > > > > > > > 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. > > > > > > > > I include QEMU patch in case if somebody wants to play with the feature. > > > > > > Exciting! Do you plan to send the QEMU patch to QEMU? > > > > Sure. After more testing, once I'm sure it's conforming to the hardware. > > A follow up after H.J.'s LPC talk: > https://linuxplumbersconf.org/event/11/contributions/1010/ > (also +Carlos) > > As far as I understood, this kernel series depends on the Intel CET patches. > > Where are these compiler-rt patches that block gcc support? Hi Xiang, Please share your compiler-rt changes for LAM.
There are already in llvm.org. One of my old patch is https://reviews.llvm.org/D102472 which has been committed by https://reviews.llvm.org/D102901 and https://reviews.llvm.org/D109790 BR Xiang -----Original Message----- From: H.J. Lu <hjl.tools@gmail.com> Sent: Wednesday, September 22, 2021 1:16 AM To: Dmitry Vyukov <dvyukov@google.com> Cc: Kirill A. Shutemov <kirill@shutemov.name>; Kirill A. Shutemov <kirill.shutemov@linux.intel.com>; Dave Hansen <dave.hansen@linux.intel.com>; Lutomirski, Andy <luto@kernel.org>; Peter Zijlstra <peterz@infradead.org>; the arch/x86 maintainers <x86@kernel.org>; Andrey Ryabinin <aryabinin@virtuozzo.com>; Alexander Potapenko <glider@google.com>; Catalin Marinas <catalin.marinas@arm.com>; Will Deacon <will@kernel.org>; Andi Kleen <ak@linux.intel.com>; Linux-MM <linux-mm@kvack.org>; LKML <linux-kernel@vger.kernel.org>; Carlos O'Donell <carlos@redhat.com>; Marco Elver <elver@google.com>; Taras Madan <tarasmadan@google.com>; Zhang, Xiang1 <xiang1.zhang@intel.com> Subject: Re: [RFC 0/9] Linear Address Masking enabling On Tue, Sep 21, 2021 at 9:52 AM Dmitry Vyukov <dvyukov@google.com> wrote: > > On Sun, 7 Feb 2021 at 15:11, Kirill A. Shutemov <kirill@shutemov.name> wrote: > > > > On Sun, Feb 07, 2021 at 09:24:23AM +0100, Dmitry Vyukov wrote: > > > On Fri, Feb 5, 2021 at 4:16 PM Kirill A. Shutemov > > > <kirill.shutemov@linux.intel.com> 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. > > > > > > > > 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 patchset is RFC quality and the code requires more testing > > > > before it can be applied. > > > > > > > > The userspace API is not finalized yet. The patchset extends API > > > > used by > > > > ARM64: PR_GET/SET_TAGGED_ADDR_CTRL. The API is adjusted to not > > > > imply ARM > > > > TBI: it now allows to request a number of bits of metadata > > > > needed and report where these bits are located in the address. > > > > > > > > There's an alternative proposal[2] for the API based on Intel > > > > CET interface. Please let us know if you prefer one over another. > > > > > > > > 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. > > > > > > > > I include QEMU patch in case if somebody wants to play with the feature. > > > > > > Exciting! Do you plan to send the QEMU patch to QEMU? > > > > Sure. After more testing, once I'm sure it's conforming to the hardware. > > A follow up after H.J.'s LPC talk: > https://linuxplumbersconf.org/event/11/contributions/1010/ > (also +Carlos) > > As far as I understood, this kernel series depends on the Intel CET patches. > > Where are these compiler-rt patches that block gcc support? Hi Xiang, Please share your compiler-rt changes for LAM. -- H.J.
On Wed, 22 Sept 2021 at 03:15, Zhang, Xiang1 <xiang1.zhang@intel.com> wrote: > > There are already in llvm.org. > One of my old patch is https://reviews.llvm.org/D102472 which has been committed by https://reviews.llvm.org/D102901 and https://reviews.llvm.org/D109790 Hi Xiang, Good sanitizer patches are upstream! Please help me to understand the status of other pieces (H.J. you probably talked about this yesterday, but I wasn't able to build a complete picture during the talk, I think it will be useful to have this in written form). 1. The presentation mentions "GCC: enable memory tagging with LAM in x86 codegen". What exactly is needed? Isn't LAM transparent for codegen? What's the status in gcc? Does a corresponding change need to be done in llvm? 2. "Enable LAM in binutils". This is already upstream in binutils 2.36, right? 3. The mentioned glibc patch: http://patchwork.ozlabs.org/project/glibc/patch/20210211173711.71736-1-hjl.tools@gmail.com/ Not upstream yet, targeting glibc 2.34. 4. "Avoid pointer operations incompatible with LAM. memmove: mask out memory tags before comparing pointers". Is this upstream? Where is the patch? Are there other similar patches? As a side note, regarding the memmove change: do we really need it? Memory regions can overlap only if they come from the same allocation/base object. If they come from different allocations, they can't overlap (undefined behavior already). 5. Do we need any additional enabling changes in clang/llvm? 6. The kernel patches (this email thread) depend on the CET patches (for the interface part only). And the CET patches is this, right? https://lore.kernel.org/linux-doc/?q=x86%2Fcet%2Fshstk 7. Do I miss anything else? H.J. please upload your slides here: https://linuxplumbersconf.org/event/11/contributions/1010/ It would help with links and copy-pasting text. FTR here is the link to the Plumbers talk: https://youtu.be/zUw0ZVXCwoM?t=10456 Thank you > BR > Xiang > > -----Original Message----- > From: H.J. Lu <hjl.tools@gmail.com> > Sent: Wednesday, September 22, 2021 1:16 AM > To: Dmitry Vyukov <dvyukov@google.com> > Cc: Kirill A. Shutemov <kirill@shutemov.name>; Kirill A. Shutemov <kirill.shutemov@linux.intel.com>; Dave Hansen <dave.hansen@linux.intel.com>; Lutomirski, Andy <luto@kernel.org>; Peter Zijlstra <peterz@infradead.org>; the arch/x86 maintainers <x86@kernel.org>; Andrey Ryabinin <aryabinin@virtuozzo.com>; Alexander Potapenko <glider@google.com>; Catalin Marinas <catalin.marinas@arm.com>; Will Deacon <will@kernel.org>; Andi Kleen <ak@linux.intel.com>; Linux-MM <linux-mm@kvack.org>; LKML <linux-kernel@vger.kernel.org>; Carlos O'Donell <carlos@redhat.com>; Marco Elver <elver@google.com>; Taras Madan <tarasmadan@google.com>; Zhang, Xiang1 <xiang1.zhang@intel.com> > Subject: Re: [RFC 0/9] Linear Address Masking enabling > > On Tue, Sep 21, 2021 at 9:52 AM Dmitry Vyukov <dvyukov@google.com> wrote: > > > > On Sun, 7 Feb 2021 at 15:11, Kirill A. Shutemov <kirill@shutemov.name> wrote: > > > > > > On Sun, Feb 07, 2021 at 09:24:23AM +0100, Dmitry Vyukov wrote: > > > > On Fri, Feb 5, 2021 at 4:16 PM Kirill A. Shutemov > > > > <kirill.shutemov@linux.intel.com> 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. > > > > > > > > > > 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 patchset is RFC quality and the code requires more testing > > > > > before it can be applied. > > > > > > > > > > The userspace API is not finalized yet. The patchset extends API > > > > > used by > > > > > ARM64: PR_GET/SET_TAGGED_ADDR_CTRL. The API is adjusted to not > > > > > imply ARM > > > > > TBI: it now allows to request a number of bits of metadata > > > > > needed and report where these bits are located in the address. > > > > > > > > > > There's an alternative proposal[2] for the API based on Intel > > > > > CET interface. Please let us know if you prefer one over another. > > > > > > > > > > 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. > > > > > > > > > > I include QEMU patch in case if somebody wants to play with the feature. > > > > > > > > Exciting! Do you plan to send the QEMU patch to QEMU? > > > > > > Sure. After more testing, once I'm sure it's conforming to the hardware. > > > > A follow up after H.J.'s LPC talk: > > https://linuxplumbersconf.org/event/11/contributions/1010/ > > (also +Carlos) > > > > As far as I understood, this kernel series depends on the Intel CET patches. > > > > Where are these compiler-rt patches that block gcc support? > > Hi Xiang, > > Please share your compiler-rt changes for LAM. > > -- > H.J.
On Wed, 22 Sept 2021 at 14:54, Dmitry Vyukov <dvyukov@google.com> wrote: > > On Wed, 22 Sept 2021 at 03:15, Zhang, Xiang1 <xiang1.zhang@intel.com> wrote: > > > > There are already in llvm.org. > > One of my old patch is https://reviews.llvm.org/D102472 which has been committed by https://reviews.llvm.org/D102901 and https://reviews.llvm.org/D109790 > > Hi Xiang, > > Good sanitizer patches are upstream! > > Please help me to understand the status of other pieces (H.J. you > probably talked about this yesterday, but I wasn't able to build a > complete picture during the talk, I think it will be useful to have > this in written form). > > 1. The presentation mentions "GCC: enable memory tagging with LAM in > x86 codegen". > What exactly is needed? Isn't LAM transparent for codegen? What's the > status in gcc? Does a corresponding change need to be done in llvm? > > 2. "Enable LAM in binutils". > This is already upstream in binutils 2.36, right? > > 3. The mentioned glibc patch: > http://patchwork.ozlabs.org/project/glibc/patch/20210211173711.71736-1-hjl.tools@gmail.com/ > Not upstream yet, targeting glibc 2.34. Do we need any support in other libc's, e.g. Android bionic? > 4. "Avoid pointer operations incompatible with LAM. memmove: mask out > memory tags before comparing pointers". > Is this upstream? Where is the patch? Are there other similar patches? > > As a side note, regarding the memmove change: do we really need it? > Memory regions can overlap only if they come from the same > allocation/base object. If they come from different allocations, they > can't overlap (undefined behavior already). > > 5. Do we need any additional enabling changes in clang/llvm? > > 6. The kernel patches (this email thread) depend on the CET patches > (for the interface part only). And the CET patches is this, right? > https://lore.kernel.org/linux-doc/?q=x86%2Fcet%2Fshstk > > 7. Do I miss anything else? > > H.J. please upload your slides here: > https://linuxplumbersconf.org/event/11/contributions/1010/ > It would help with links and copy-pasting text. > > FTR here is the link to the Plumbers talk: > https://youtu.be/zUw0ZVXCwoM?t=10456 > > Thank you > > > > BR > > Xiang > > > > -----Original Message----- > > From: H.J. Lu <hjl.tools@gmail.com> > > Sent: Wednesday, September 22, 2021 1:16 AM > > To: Dmitry Vyukov <dvyukov@google.com> > > Cc: Kirill A. Shutemov <kirill@shutemov.name>; Kirill A. Shutemov <kirill.shutemov@linux.intel.com>; Dave Hansen <dave.hansen@linux.intel.com>; Lutomirski, Andy <luto@kernel.org>; Peter Zijlstra <peterz@infradead.org>; the arch/x86 maintainers <x86@kernel.org>; Andrey Ryabinin <aryabinin@virtuozzo.com>; Alexander Potapenko <glider@google.com>; Catalin Marinas <catalin.marinas@arm.com>; Will Deacon <will@kernel.org>; Andi Kleen <ak@linux.intel.com>; Linux-MM <linux-mm@kvack.org>; LKML <linux-kernel@vger.kernel.org>; Carlos O'Donell <carlos@redhat.com>; Marco Elver <elver@google.com>; Taras Madan <tarasmadan@google.com>; Zhang, Xiang1 <xiang1.zhang@intel.com> > > Subject: Re: [RFC 0/9] Linear Address Masking enabling > > > > On Tue, Sep 21, 2021 at 9:52 AM Dmitry Vyukov <dvyukov@google.com> wrote: > > > > > > On Sun, 7 Feb 2021 at 15:11, Kirill A. Shutemov <kirill@shutemov.name> wrote: > > > > > > > > On Sun, Feb 07, 2021 at 09:24:23AM +0100, Dmitry Vyukov wrote: > > > > > On Fri, Feb 5, 2021 at 4:16 PM Kirill A. Shutemov > > > > > <kirill.shutemov@linux.intel.com> 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. > > > > > > > > > > > > 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 patchset is RFC quality and the code requires more testing > > > > > > before it can be applied. > > > > > > > > > > > > The userspace API is not finalized yet. The patchset extends API > > > > > > used by > > > > > > ARM64: PR_GET/SET_TAGGED_ADDR_CTRL. The API is adjusted to not > > > > > > imply ARM > > > > > > TBI: it now allows to request a number of bits of metadata > > > > > > needed and report where these bits are located in the address. > > > > > > > > > > > > There's an alternative proposal[2] for the API based on Intel > > > > > > CET interface. Please let us know if you prefer one over another. > > > > > > > > > > > > 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. > > > > > > > > > > > > I include QEMU patch in case if somebody wants to play with the feature. > > > > > > > > > > Exciting! Do you plan to send the QEMU patch to QEMU? > > > > > > > > Sure. After more testing, once I'm sure it's conforming to the hardware. > > > > > > A follow up after H.J.'s LPC talk: > > > https://linuxplumbersconf.org/event/11/contributions/1010/ > > > (also +Carlos) > > > > > > As far as I understood, this kernel series depends on the Intel CET patches. > > > > > > Where are these compiler-rt patches that block gcc support? > > > > Hi Xiang, > > > > Please share your compiler-rt changes for LAM. > > > > -- > > H.J.
On Wed, Sep 22, 2021 at 10:03:32PM +0200, Dmitry Vyukov wrote: > > 6. The kernel patches (this email thread) depend on the CET patches > > (for the interface part only). And the CET patches is this, right? > > https://lore.kernel.org/linux-doc/?q=x86%2Fcet%2Fshstk CET is two part patchset: shstk and ibt. Look for x86/cet/ibt. At this point we plan to use CET interface, but it's not settled until it actually lands upstream.
On Wed, Sep 22, 2021 at 5:54 AM Dmitry Vyukov <dvyukov@google.com> wrote: > > On Wed, 22 Sept 2021 at 03:15, Zhang, Xiang1 <xiang1.zhang@intel.com> wrote: > > > > There are already in llvm.org. > > One of my old patch is https://reviews.llvm.org/D102472 which has been committed by https://reviews.llvm.org/D102901 and https://reviews.llvm.org/D109790 > > Hi Xiang, > > Good sanitizer patches are upstream! > > Please help me to understand the status of other pieces (H.J. you > probably talked about this yesterday, but I wasn't able to build a > complete picture during the talk, I think it will be useful to have > this in written form). > > 1. The presentation mentions "GCC: enable memory tagging with LAM in > x86 codegen". > What exactly is needed? Isn't LAM transparent for codegen? What's the > status in gcc? Does a corresponding change need to be done in llvm? The current LAM enabled GCC is on users/intel/lam/master branch at https://gitlab.com/x86-gcc/gcc/-/tree/users/intel/lam/master Hongtao, please sync libsanitizer with compiler-rt and check if compiler-rt is up to date. The LAM enabled GCC run-time uses the proposed tagged address API. > 2. "Enable LAM in binutils". > This is already upstream in binutils 2.36, right? Correct. > 3. The mentioned glibc patch: > http://patchwork.ozlabs.org/project/glibc/patch/20210211173711.71736-1-hjl.tools@gmail.com/ > Not upstream yet, targeting glibc 2.34. It is targeting glibc 2.35 now. > 4. "Avoid pointer operations incompatible with LAM. memmove: mask out > memory tags before comparing pointers". > Is this upstream? Where is the patch? Are there other similar patches? The LAM enabled glibc is on users/intel/lam/master branch at: https://gitlab.com/x86-glibc/glibc/-/tree/users/intel/lam/master I am considering moving the tagged address API to libc_nonshared.a for easy backport. > As a side note, regarding the memmove change: do we really need it? > Memory regions can overlap only if they come from the same > allocation/base object. If they come from different allocations, they > can't overlap (undefined behavior already). The change isn't needed and has been removed. > 5. Do we need any additional enabling changes in clang/llvm? I proposed the tagged address API to support LAM. compiler-rt should use it. > 6. The kernel patches (this email thread) depend on the CET patches > (for the interface part only). And the CET patches is this, right? > https://lore.kernel.org/linux-doc/?q=x86%2Fcet%2Fshstk Yes. > 7. Do I miss anything else? No. > H.J. please upload your slides here: > https://linuxplumbersconf.org/event/11/contributions/1010/ > It would help with links and copy-pasting text. Done. H.J. > FTR here is the link to the Plumbers talk: > https://youtu.be/zUw0ZVXCwoM?t=10456 > > Thank you > > > > BR > > Xiang > > > > -----Original Message----- > > From: H.J. Lu <hjl.tools@gmail.com> > > Sent: Wednesday, September 22, 2021 1:16 AM > > To: Dmitry Vyukov <dvyukov@google.com> > > Cc: Kirill A. Shutemov <kirill@shutemov.name>; Kirill A. Shutemov <kirill.shutemov@linux.intel.com>; Dave Hansen <dave.hansen@linux.intel.com>; Lutomirski, Andy <luto@kernel.org>; Peter Zijlstra <peterz@infradead.org>; the arch/x86 maintainers <x86@kernel.org>; Andrey Ryabinin <aryabinin@virtuozzo.com>; Alexander Potapenko <glider@google.com>; Catalin Marinas <catalin.marinas@arm.com>; Will Deacon <will@kernel.org>; Andi Kleen <ak@linux.intel.com>; Linux-MM <linux-mm@kvack.org>; LKML <linux-kernel@vger.kernel.org>; Carlos O'Donell <carlos@redhat.com>; Marco Elver <elver@google.com>; Taras Madan <tarasmadan@google.com>; Zhang, Xiang1 <xiang1.zhang@intel.com> > > Subject: Re: [RFC 0/9] Linear Address Masking enabling > > > > On Tue, Sep 21, 2021 at 9:52 AM Dmitry Vyukov <dvyukov@google.com> wrote: > > > > > > On Sun, 7 Feb 2021 at 15:11, Kirill A. Shutemov <kirill@shutemov.name> wrote: > > > > > > > > On Sun, Feb 07, 2021 at 09:24:23AM +0100, Dmitry Vyukov wrote: > > > > > On Fri, Feb 5, 2021 at 4:16 PM Kirill A. Shutemov > > > > > <kirill.shutemov@linux.intel.com> 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. > > > > > > > > > > > > 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 patchset is RFC quality and the code requires more testing > > > > > > before it can be applied. > > > > > > > > > > > > The userspace API is not finalized yet. The patchset extends API > > > > > > used by > > > > > > ARM64: PR_GET/SET_TAGGED_ADDR_CTRL. The API is adjusted to not > > > > > > imply ARM > > > > > > TBI: it now allows to request a number of bits of metadata > > > > > > needed and report where these bits are located in the address. > > > > > > > > > > > > There's an alternative proposal[2] for the API based on Intel > > > > > > CET interface. Please let us know if you prefer one over another. > > > > > > > > > > > > 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. > > > > > > > > > > > > I include QEMU patch in case if somebody wants to play with the feature. > > > > > > > > > > Exciting! Do you plan to send the QEMU patch to QEMU? > > > > > > > > Sure. After more testing, once I'm sure it's conforming to the hardware. > > > > > > A follow up after H.J.'s LPC talk: > > > https://linuxplumbersconf.org/event/11/contributions/1010/ > > > (also +Carlos) > > > > > > As far as I understood, this kernel series depends on the Intel CET patches. > > > > > > Where are these compiler-rt patches that block gcc support? > > > > Hi Xiang, > > > > Please share your compiler-rt changes for LAM. > > > > -- > > H.J. -- H.J.
On Wed, Sep 22, 2021 at 1:03 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > On Wed, 22 Sept 2021 at 14:54, Dmitry Vyukov <dvyukov@google.com> wrote: > > > > On Wed, 22 Sept 2021 at 03:15, Zhang, Xiang1 <xiang1.zhang@intel.com> wrote: > > > > > > There are already in llvm.org. > > > One of my old patch is https://reviews.llvm.org/D102472 which has been committed by https://reviews.llvm.org/D102901 and https://reviews.llvm.org/D109790 > > > > Hi Xiang, > > > > Good sanitizer patches are upstream! > > > > Please help me to understand the status of other pieces (H.J. you > > probably talked about this yesterday, but I wasn't able to build a > > complete picture during the talk, I think it will be useful to have > > this in written form). > > > > 1. The presentation mentions "GCC: enable memory tagging with LAM in > > x86 codegen". > > What exactly is needed? Isn't LAM transparent for codegen? What's the > > status in gcc? Does a corresponding change need to be done in llvm? > > > > 2. "Enable LAM in binutils". > > This is already upstream in binutils 2.36, right? > > > > 3. The mentioned glibc patch: > > http://patchwork.ozlabs.org/project/glibc/patch/20210211173711.71736-1-hjl.tools@gmail.com/ > > Not upstream yet, targeting glibc 2.34. > > Do we need any support in other libc's, e.g. Android bionic? Here is my tagged address API proposal: https://sourceware.org/pipermail/libc-alpha/2021-August/130382.html > > 4. "Avoid pointer operations incompatible with LAM. memmove: mask out > > memory tags before comparing pointers". > > Is this upstream? Where is the patch? Are there other similar patches? > > > > As a side note, regarding the memmove change: do we really need it? > > Memory regions can overlap only if they come from the same > > allocation/base object. If they come from different allocations, they > > can't overlap (undefined behavior already). > > > > 5. Do we need any additional enabling changes in clang/llvm? > > > > 6. The kernel patches (this email thread) depend on the CET patches > > (for the interface part only). And the CET patches is this, right? > > https://lore.kernel.org/linux-doc/?q=x86%2Fcet%2Fshstk > > > > 7. Do I miss anything else? > > > > H.J. please upload your slides here: > > https://linuxplumbersconf.org/event/11/contributions/1010/ > > It would help with links and copy-pasting text. > > > > FTR here is the link to the Plumbers talk: > > https://youtu.be/zUw0ZVXCwoM?t=10456 > > > > Thank you > > > > > > > BR > > > Xiang > > > > > > -----Original Message----- > > > From: H.J. Lu <hjl.tools@gmail.com> > > > Sent: Wednesday, September 22, 2021 1:16 AM > > > To: Dmitry Vyukov <dvyukov@google.com> > > > Cc: Kirill A. Shutemov <kirill@shutemov.name>; Kirill A. Shutemov <kirill.shutemov@linux.intel.com>; Dave Hansen <dave.hansen@linux.intel.com>; Lutomirski, Andy <luto@kernel.org>; Peter Zijlstra <peterz@infradead.org>; the arch/x86 maintainers <x86@kernel.org>; Andrey Ryabinin <aryabinin@virtuozzo.com>; Alexander Potapenko <glider@google.com>; Catalin Marinas <catalin.marinas@arm.com>; Will Deacon <will@kernel.org>; Andi Kleen <ak@linux.intel.com>; Linux-MM <linux-mm@kvack.org>; LKML <linux-kernel@vger.kernel.org>; Carlos O'Donell <carlos@redhat.com>; Marco Elver <elver@google.com>; Taras Madan <tarasmadan@google.com>; Zhang, Xiang1 <xiang1.zhang@intel.com> > > > Subject: Re: [RFC 0/9] Linear Address Masking enabling > > > > > > On Tue, Sep 21, 2021 at 9:52 AM Dmitry Vyukov <dvyukov@google.com> wrote: > > > > > > > > On Sun, 7 Feb 2021 at 15:11, Kirill A. Shutemov <kirill@shutemov.name> wrote: > > > > > > > > > > On Sun, Feb 07, 2021 at 09:24:23AM +0100, Dmitry Vyukov wrote: > > > > > > On Fri, Feb 5, 2021 at 4:16 PM Kirill A. Shutemov > > > > > > <kirill.shutemov@linux.intel.com> 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. > > > > > > > > > > > > > > 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 patchset is RFC quality and the code requires more testing > > > > > > > before it can be applied. > > > > > > > > > > > > > > The userspace API is not finalized yet. The patchset extends API > > > > > > > used by > > > > > > > ARM64: PR_GET/SET_TAGGED_ADDR_CTRL. The API is adjusted to not > > > > > > > imply ARM > > > > > > > TBI: it now allows to request a number of bits of metadata > > > > > > > needed and report where these bits are located in the address. > > > > > > > > > > > > > > There's an alternative proposal[2] for the API based on Intel > > > > > > > CET interface. Please let us know if you prefer one over another. > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > I include QEMU patch in case if somebody wants to play with the feature. > > > > > > > > > > > > Exciting! Do you plan to send the QEMU patch to QEMU? > > > > > > > > > > Sure. After more testing, once I'm sure it's conforming to the hardware. > > > > > > > > A follow up after H.J.'s LPC talk: > > > > https://linuxplumbersconf.org/event/11/contributions/1010/ > > > > (also +Carlos) > > > > > > > > As far as I understood, this kernel series depends on the Intel CET patches. > > > > > > > > Where are these compiler-rt patches that block gcc support? > > > > > > Hi Xiang, > > > > > > Please share your compiler-rt changes for LAM. > > > > > > -- > > > H.J.
On Thu, 23 Sept 2021 at 02:15, H.J. Lu <hjl.tools@gmail.com> wrote: > > > On Wed, 22 Sept 2021 at 03:15, Zhang, Xiang1 <xiang1.zhang@intel.com> wrote: > > > > > > > > There are already in llvm.org. > > > > One of my old patch is https://reviews.llvm.org/D102472 which has been committed by https://reviews.llvm.org/D102901 and https://reviews.llvm.org/D109790 > > > > > > Hi Xiang, > > > > > > Good sanitizer patches are upstream! > > > > > > Please help me to understand the status of other pieces (H.J. you > > > probably talked about this yesterday, but I wasn't able to build a > > > complete picture during the talk, I think it will be useful to have > > > this in written form). > > > > > > 1. The presentation mentions "GCC: enable memory tagging with LAM in > > > x86 codegen". > > > What exactly is needed? Isn't LAM transparent for codegen? What's the > > > status in gcc? Does a corresponding change need to be done in llvm? > > > > > > 2. "Enable LAM in binutils". > > > This is already upstream in binutils 2.36, right? > > > > > > 3. The mentioned glibc patch: > > > http://patchwork.ozlabs.org/project/glibc/patch/20210211173711.71736-1-hjl.tools@gmail.com/ > > > Not upstream yet, targeting glibc 2.34. > > > > Do we need any support in other libc's, e.g. Android bionic? > > Here is my tagged address API proposal: > > https://sourceware.org/pipermail/libc-alpha/2021-August/130382.html Thank you, I got the large picture now. > > > 4. "Avoid pointer operations incompatible with LAM. memmove: mask out > > > memory tags before comparing pointers". > > > Is this upstream? Where is the patch? Are there other similar patches? > > > > > > As a side note, regarding the memmove change: do we really need it? > > > Memory regions can overlap only if they come from the same > > > allocation/base object. If they come from different allocations, they > > > can't overlap (undefined behavior already). > > > > > > 5. Do we need any additional enabling changes in clang/llvm? > > > > > > 6. The kernel patches (this email thread) depend on the CET patches > > > (for the interface part only). And the CET patches is this, right? > > > https://lore.kernel.org/linux-doc/?q=x86%2Fcet%2Fshstk > > > > > > 7. Do I miss anything else? > > > > > > H.J. please upload your slides here: > > > https://linuxplumbersconf.org/event/11/contributions/1010/ > > > It would help with links and copy-pasting text. > > > > > > FTR here is the link to the Plumbers talk: > > > https://youtu.be/zUw0ZVXCwoM?t=10456 > > > > > > Thank you > > > > > > > > > > BR > > > > Xiang > > > > > > > > -----Original Message----- > > > > From: H.J. Lu <hjl.tools@gmail.com> > > > > Sent: Wednesday, September 22, 2021 1:16 AM > > > > To: Dmitry Vyukov <dvyukov@google.com> > > > > Cc: Kirill A. Shutemov <kirill@shutemov.name>; Kirill A. Shutemov <kirill.shutemov@linux.intel.com>; Dave Hansen <dave.hansen@linux.intel.com>; Lutomirski, Andy <luto@kernel.org>; Peter Zijlstra <peterz@infradead.org>; the arch/x86 maintainers <x86@kernel.org>; Andrey Ryabinin <aryabinin@virtuozzo.com>; Alexander Potapenko <glider@google.com>; Catalin Marinas <catalin.marinas@arm.com>; Will Deacon <will@kernel.org>; Andi Kleen <ak@linux.intel.com>; Linux-MM <linux-mm@kvack.org>; LKML <linux-kernel@vger.kernel.org>; Carlos O'Donell <carlos@redhat.com>; Marco Elver <elver@google.com>; Taras Madan <tarasmadan@google.com>; Zhang, Xiang1 <xiang1.zhang@intel.com> > > > > Subject: Re: [RFC 0/9] Linear Address Masking enabling > > > > > > > > On Tue, Sep 21, 2021 at 9:52 AM Dmitry Vyukov <dvyukov@google.com> wrote: > > > > > > > > > > On Sun, 7 Feb 2021 at 15:11, Kirill A. Shutemov <kirill@shutemov.name> wrote: > > > > > > > > > > > > On Sun, Feb 07, 2021 at 09:24:23AM +0100, Dmitry Vyukov wrote: > > > > > > > On Fri, Feb 5, 2021 at 4:16 PM Kirill A. Shutemov > > > > > > > <kirill.shutemov@linux.intel.com> 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. > > > > > > > > > > > > > > > > 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 patchset is RFC quality and the code requires more testing > > > > > > > > before it can be applied. > > > > > > > > > > > > > > > > The userspace API is not finalized yet. The patchset extends API > > > > > > > > used by > > > > > > > > ARM64: PR_GET/SET_TAGGED_ADDR_CTRL. The API is adjusted to not > > > > > > > > imply ARM > > > > > > > > TBI: it now allows to request a number of bits of metadata > > > > > > > > needed and report where these bits are located in the address. > > > > > > > > > > > > > > > > There's an alternative proposal[2] for the API based on Intel > > > > > > > > CET interface. Please let us know if you prefer one over another. > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > I include QEMU patch in case if somebody wants to play with the feature. > > > > > > > > > > > > > > Exciting! Do you plan to send the QEMU patch to QEMU? > > > > > > > > > > > > Sure. After more testing, once I'm sure it's conforming to the hardware. > > > > > > > > > > A follow up after H.J.'s LPC talk: > > > > > https://linuxplumbersconf.org/event/11/contributions/1010/ > > > > > (also +Carlos) > > > > > > > > > > As far as I understood, this kernel series depends on the Intel CET patches. > > > > > > > > > > Where are these compiler-rt patches that block gcc support? > > > > > > > > Hi Xiang, > > > > > > > > Please share your compiler-rt changes for LAM. > > > > > > > > -- > > > > H.J. > > > > -- > H.J.
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 patchset is RFC quality and the code requires more testing before it can be applied. The userspace API is not finalized yet. The patchset extends API used by ARM64: PR_GET/SET_TAGGED_ADDR_CTRL. The API is adjusted to not imply ARM TBI: it now allows to request a number of bits of metadata needed and report where these bits are located in the address. There's an alternative proposal[2] for the API based on Intel CET interface. Please let us know if you prefer one over another. 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. I include QEMU patch in case if somebody wants to play with the feature. The branch: git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git lam Any comments are welcome. [1] ISE, Chapter 14. https://software.intel.com/content/dam/develop/external/us/en/documents-tps/architecture-instruction-set-extensions-programming-reference.pdf [2] https://github.com/hjl-tools/linux/commit/e85fa032e5b276ddf17edd056f92f599db9e8369 Kirill A. Shutemov (9): mm, arm64: Update PR_SET/GET_TAGGED_ADDR_CTRL interface x86/mm: Fix CR3_ADDR_MASK x86: CPUID and CR3/CR4 flags for Linear Address Masking x86/mm: Introduce TIF_LAM_U57 and TIF_LAM_U48 x86/mm: Provide untagged_addr() helper x86/uaccess: Remove tags from the address before checking x86/mm: Handle tagged memory accesses from kernel threads x86/mm: Make LAM_U48 and mappings above 47-bits mutually exclusive x86/mm: Implement PR_SET/GET_TAGGED_ADDR_CTRL with LAM arch/arm64/include/asm/processor.h | 12 +- arch/arm64/kernel/process.c | 45 +++++- arch/arm64/kernel/ptrace.c | 4 +- arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/elf.h | 3 +- arch/x86/include/asm/mmu.h | 1 + arch/x86/include/asm/mmu_context.h | 13 ++ arch/x86/include/asm/page_32.h | 3 + arch/x86/include/asm/page_64.h | 19 +++ arch/x86/include/asm/processor-flags.h | 2 +- arch/x86/include/asm/processor.h | 10 ++ arch/x86/include/asm/thread_info.h | 9 +- arch/x86/include/asm/tlbflush.h | 5 + arch/x86/include/asm/uaccess.h | 16 +- arch/x86/include/uapi/asm/processor-flags.h | 6 + arch/x86/kernel/process_64.c | 145 ++++++++++++++++++ arch/x86/kernel/sys_x86_64.c | 5 +- arch/x86/mm/hugetlbpage.c | 6 +- arch/x86/mm/mmap.c | 9 +- arch/x86/mm/tlb.c | 124 +++++++++++++-- kernel/sys.c | 14 +- .../testing/selftests/arm64/tags/tags_test.c | 31 ---- .../selftests/{arm64 => vm}/tags/.gitignore | 0 .../selftests/{arm64 => vm}/tags/Makefile | 0 .../{arm64 => vm}/tags/run_tags_test.sh | 0 tools/testing/selftests/vm/tags/tags_test.c | 57 +++++++ 26 files changed, 464 insertions(+), 76 deletions(-) delete mode 100644 tools/testing/selftests/arm64/tags/tags_test.c rename tools/testing/selftests/{arm64 => vm}/tags/.gitignore (100%) rename tools/testing/selftests/{arm64 => vm}/tags/Makefile (100%) rename tools/testing/selftests/{arm64 => vm}/tags/run_tags_test.sh (100%) create mode 100644 tools/testing/selftests/vm/tags/tags_test.c