From: Catalin Marinas <catalin.marinas@arm.com> To: Szabolcs Nagy <szabolcs.nagy@arm.com> Cc: Dave Martin <Dave.Martin@arm.com>, linux-arch@vger.kernel.org, Peter Collingbourne <pcc@google.com>, Andrey Konovalov <andreyknvl@google.com>, Kevin Brodsky <kevin.brodsky@arm.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Vincenzo Frascino <vincenzo.frascino@arm.com>, Will Deacon <will@kernel.org>, linux-arm-kernel@lists.infradead.org, nd@arm.com Subject: Re: [PATCH v7 29/29] arm64: mte: Add Memory Tagging Extension documentation Date: Wed, 19 Aug 2020 10:54:56 +0100 [thread overview] Message-ID: <20200819095453.GA86@DESKTOP-O1885NU.localdomain> (raw) In-Reply-To: <20200812124520.GP14398@arm.com> On Wed, Aug 12, 2020 at 01:45:21PM +0100, Szabolcs Nagy wrote: > On 08/11/2020 18:20, Catalin Marinas wrote: > > If we allow such mixed object support with stack tagging enabled at > > dlopen, PROT_MTE would need to be turned on for each thread stack. This > > wouldn't require synchronisation, only knowing where the thread stacks > > are, but you'd need to make sure threads don't call into the new library > > until the stacks have been mprotect'ed. Doing this midway through a > > function execution may corrupt the tags. > > > > So I'm not sure how safe any of this is without explicit user > > synchronisation (i.e. don't call into the library until all threads have > > been updated). Even changing options like GCR_EL1.Excl across multiple > > threads may have unwanted effects. See this comment from Peter, the > > difference being that instead of an explicit prctl() call on the current > > stack, another thread would do it: > > > > https://lore.kernel.org/linux-arch/CAMn1gO5rhOG1W+nVe103v=smvARcFFp_Ct9XqH2Ca4BUMfpDdg@mail.gmail.com/ > > there is no midway problem: the libc (ld.so) would do the PROT_MTE at > dlopen time based on some elf marking (which can be handled before > relocation processing, so before library code can run, the midway > problem happens when a library, e.g libc, wants to turn on stack > tagging on itself). OK, that makes sense, you can't call into the new object until the relocations have been resolved. > the libc already does this when a library is loaded that requires > executable stack (it marks stacks as PROT_EXEC at dlopen time or fails > the dlopen if that is not possible, this does not require running code > in other threads, only synchronization with thread creation and exit. > but changing the check mode for mte needs per thread code execution.). > > i'm not entirely sure if this is a good idea, but i expect stack > tagging not to be used in the libc (because libc needs to run on all > hw and we don't yet have a backward compatible stack tagging > solution), In theory, you could have two libc deployed in your distro and ldd gets smarter to pick the right one. I still hope we'd find a compromise with stack tagging and single binary. > so stack tagging should work when only some elf modules in a process > are built with it, which implies that enabling it at dlopen time > should work otherwise it will not be very useful. There is still the small risk of an old object using tagged pointers to the stack. Since the stack would be shared between such objects, turning PROT_MTE on would cause issues. Hopefully such problems are minor and not really a concern for the kernel. > do tag checks have overhead if PROT_MTE is not used? i'd expect some > checks are still done at memory access. (and the tagged address > syscall abi has to be in use.) My understanding from talking to hardware engineers is that there won't be an overhead if PROT_MTE is not used, no tags being fetched or checked. But I can't guarantee until we get real silicon. > turning sync tag checks on early would enable the most of the > interesting usecases (only PROT_MTE has to be handled at runtime not > the prctls. however i don't yet know how userspace will deal with > compat issues, i.e. it may not be valid to unconditionally turn tag > checks on early). If we change the defaults so that no prctl() is required for the standard use-case, it would solve most of the common deployment issues: 1. Tagged address ABI default on when HWCAP2_MTE is present 2. Synchronous TCF by default 3. GCR_EL1.Excl allows all tags except 0 by default Any other configuration diverging from the above is considered specialist deployment and will have to issue the prctl() on a per-thread basis. Compat issues in user-space will be dealt with via environment variables but pretty much on/off rather than fine-grained tag checking mode. So for glibc, you'd have only _MTAG=0 or 1 and the only effect is using PROT_MTE + tagged pointers or no-PROT_MTE + tag 0. > > In the presence of stack tagging, I think any subsequent MTE config > > change across all threads is unsafe, irrespective of whether it's done > > by the kernel or user via SIGUSRx. I think the best we can do here is > > start with more appropriate defaults or enable them based on an ELF note > > before the application is started. The dynamic loader would not have to > > do anything extra here. > > > > If we ignore stack tagging, the global configuration change may be > > achievable. I think for the MTE bits, this could be done lazily by the > > libc (e.g. on malloc()/free() call). The tag checking won't happen > > before such calls unless we change the kernel defaults. There is still > > the tagged address ABI enabling, could this be done lazily on syscall by > > the libc? If not, the kernel could synchronise (force) this on syscall > > entry from each thread based on some global prctl() bit. > > i think the interesting use-cases are all about changing mte settings > before mte is in use in any way but after there are multiple threads. > (the async -> sync mode change on tag faults is i think less > interesting to the gnu linux world.) So let's consider async/sync/no-check specialist uses and glibc would not have to handle them. I don't think async mode is useful on its own unless you have a way to turn on sync mode at run-time for more precise error identification (well, hoping that it will happen again). > i guess lazy syscall abi switch works, but it is ugly: raw syscall > usage will be problematic and doing checks before calling into the > vdso might have unwanted overhead. This lazy ABI switch could be handled by the kernel, though I wonder whether we should just relax it permanently when HWCAP2_MTE is present. -- Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com> To: Szabolcs Nagy <szabolcs.nagy@arm.com> Cc: linux-arch@vger.kernel.org, nd@arm.com, Will Deacon <will@kernel.org>, Andrey Konovalov <andreyknvl@google.com>, Kevin Brodsky <kevin.brodsky@arm.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Vincenzo Frascino <vincenzo.frascino@arm.com>, Peter Collingbourne <pcc@google.com>, Dave Martin <Dave.Martin@arm.com>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v7 29/29] arm64: mte: Add Memory Tagging Extension documentation Date: Wed, 19 Aug 2020 10:54:56 +0100 [thread overview] Message-ID: <20200819095453.GA86@DESKTOP-O1885NU.localdomain> (raw) In-Reply-To: <20200812124520.GP14398@arm.com> On Wed, Aug 12, 2020 at 01:45:21PM +0100, Szabolcs Nagy wrote: > On 08/11/2020 18:20, Catalin Marinas wrote: > > If we allow such mixed object support with stack tagging enabled at > > dlopen, PROT_MTE would need to be turned on for each thread stack. This > > wouldn't require synchronisation, only knowing where the thread stacks > > are, but you'd need to make sure threads don't call into the new library > > until the stacks have been mprotect'ed. Doing this midway through a > > function execution may corrupt the tags. > > > > So I'm not sure how safe any of this is without explicit user > > synchronisation (i.e. don't call into the library until all threads have > > been updated). Even changing options like GCR_EL1.Excl across multiple > > threads may have unwanted effects. See this comment from Peter, the > > difference being that instead of an explicit prctl() call on the current > > stack, another thread would do it: > > > > https://lore.kernel.org/linux-arch/CAMn1gO5rhOG1W+nVe103v=smvARcFFp_Ct9XqH2Ca4BUMfpDdg@mail.gmail.com/ > > there is no midway problem: the libc (ld.so) would do the PROT_MTE at > dlopen time based on some elf marking (which can be handled before > relocation processing, so before library code can run, the midway > problem happens when a library, e.g libc, wants to turn on stack > tagging on itself). OK, that makes sense, you can't call into the new object until the relocations have been resolved. > the libc already does this when a library is loaded that requires > executable stack (it marks stacks as PROT_EXEC at dlopen time or fails > the dlopen if that is not possible, this does not require running code > in other threads, only synchronization with thread creation and exit. > but changing the check mode for mte needs per thread code execution.). > > i'm not entirely sure if this is a good idea, but i expect stack > tagging not to be used in the libc (because libc needs to run on all > hw and we don't yet have a backward compatible stack tagging > solution), In theory, you could have two libc deployed in your distro and ldd gets smarter to pick the right one. I still hope we'd find a compromise with stack tagging and single binary. > so stack tagging should work when only some elf modules in a process > are built with it, which implies that enabling it at dlopen time > should work otherwise it will not be very useful. There is still the small risk of an old object using tagged pointers to the stack. Since the stack would be shared between such objects, turning PROT_MTE on would cause issues. Hopefully such problems are minor and not really a concern for the kernel. > do tag checks have overhead if PROT_MTE is not used? i'd expect some > checks are still done at memory access. (and the tagged address > syscall abi has to be in use.) My understanding from talking to hardware engineers is that there won't be an overhead if PROT_MTE is not used, no tags being fetched or checked. But I can't guarantee until we get real silicon. > turning sync tag checks on early would enable the most of the > interesting usecases (only PROT_MTE has to be handled at runtime not > the prctls. however i don't yet know how userspace will deal with > compat issues, i.e. it may not be valid to unconditionally turn tag > checks on early). If we change the defaults so that no prctl() is required for the standard use-case, it would solve most of the common deployment issues: 1. Tagged address ABI default on when HWCAP2_MTE is present 2. Synchronous TCF by default 3. GCR_EL1.Excl allows all tags except 0 by default Any other configuration diverging from the above is considered specialist deployment and will have to issue the prctl() on a per-thread basis. Compat issues in user-space will be dealt with via environment variables but pretty much on/off rather than fine-grained tag checking mode. So for glibc, you'd have only _MTAG=0 or 1 and the only effect is using PROT_MTE + tagged pointers or no-PROT_MTE + tag 0. > > In the presence of stack tagging, I think any subsequent MTE config > > change across all threads is unsafe, irrespective of whether it's done > > by the kernel or user via SIGUSRx. I think the best we can do here is > > start with more appropriate defaults or enable them based on an ELF note > > before the application is started. The dynamic loader would not have to > > do anything extra here. > > > > If we ignore stack tagging, the global configuration change may be > > achievable. I think for the MTE bits, this could be done lazily by the > > libc (e.g. on malloc()/free() call). The tag checking won't happen > > before such calls unless we change the kernel defaults. There is still > > the tagged address ABI enabling, could this be done lazily on syscall by > > the libc? If not, the kernel could synchronise (force) this on syscall > > entry from each thread based on some global prctl() bit. > > i think the interesting use-cases are all about changing mte settings > before mte is in use in any way but after there are multiple threads. > (the async -> sync mode change on tag faults is i think less > interesting to the gnu linux world.) So let's consider async/sync/no-check specialist uses and glibc would not have to handle them. I don't think async mode is useful on its own unless you have a way to turn on sync mode at run-time for more precise error identification (well, hoping that it will happen again). > i guess lazy syscall abi switch works, but it is ugly: raw syscall > usage will be problematic and doing checks before calling into the > vdso might have unwanted overhead. This lazy ABI switch could be handled by the kernel, though I wonder whether we should just relax it permanently when HWCAP2_MTE is present. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-08-19 9:55 UTC|newest] Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-15 17:08 [PATCH v7 00/26] arm64: Memory Tagging Extension user-space support Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 01/29] arm64: mte: system register definitions Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 02/29] arm64: mte: CPU feature detection and initial sysreg configuration Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 03/29] arm64: mte: Use Normal Tagged attributes for the linear map Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 04/29] arm64: mte: Add specific SIGSEGV codes Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 05/29] arm64: mte: Handle synchronous and asynchronous tag check faults Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 06/29] mm: Add PG_arch_2 page flag Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 07/29] mm: Preserve the PG_arch_2 flag in __split_huge_page_tail() Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 08/29] arm64: mte: Clear the tags when a page is mapped in user-space with PROT_MTE Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 09/29] arm64: mte: Tags-aware copy_{user_,}highpage() implementations Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 10/29] arm64: Avoid unnecessary clear_user_page() indirection Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 11/29] arm64: mte: Tags-aware aware memcmp_pages() implementation Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 12/29] arm64: mte: Handle the MAIR_EL1 changes for late CPU bring-up Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 13/29] mm: Introduce arch_calc_vm_flag_bits() Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 14/29] arm64: mte: Add PROT_MTE support to mmap() and mprotect() Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 15/29] mm: Introduce arch_validate_flags() Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 16/29] arm64: mte: Validate the PROT_MTE request via arch_validate_flags() Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 17/29] mm: Allow arm64 mmap(PROT_MTE) on RAM-based files Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 18/29] arm64: mte: Allow user control of the tag check mode via prctl() Catalin Marinas 2020-07-20 15:30 ` Kevin Brodsky 2020-07-20 15:30 ` Kevin Brodsky 2020-07-20 17:00 ` Dave Martin 2020-07-20 17:00 ` Dave Martin 2020-07-22 10:28 ` Catalin Marinas 2020-07-22 10:28 ` Catalin Marinas 2020-07-23 19:33 ` Kevin Brodsky 2020-07-23 19:33 ` Kevin Brodsky 2020-07-22 11:09 ` Catalin Marinas 2020-07-22 11:09 ` Catalin Marinas 2020-08-04 19:34 ` Kevin Brodsky 2020-08-04 19:34 ` Kevin Brodsky 2020-08-05 9:24 ` Catalin Marinas 2020-08-05 9:24 ` Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 19/29] arm64: mte: Allow user control of the generated random tags " Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 20/29] arm64: mte: Restore the GCR_EL1 register after a suspend Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 21/29] arm64: mte: Allow {set,get}_tagged_addr_ctrl() on non-current tasks Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 22/29] arm64: mte: ptrace: Add PTRACE_{PEEK,POKE}MTETAGS support Catalin Marinas 2020-08-13 14:01 ` Luis Machado 2020-08-13 14:01 ` Luis Machado 2020-08-22 10:56 ` Catalin Marinas 2020-08-22 10:56 ` Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 23/29] arm64: mte: ptrace: Add NT_ARM_TAGGED_ADDR_CTRL regset Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 24/29] fs: Handle intra-page faults in copy_mount_options() Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 25/29] mm: Add arch hooks for saving/restoring tags Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 26/29] arm64: mte: Enable swap of tagged pages Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 27/29] arm64: mte: Save tags when hibernating Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 28/29] arm64: mte: Kconfig entry Catalin Marinas 2020-07-15 17:08 ` [PATCH v7 29/29] arm64: mte: Add Memory Tagging Extension documentation Catalin Marinas 2020-07-27 16:36 ` Szabolcs Nagy 2020-07-27 16:36 ` Szabolcs Nagy 2020-07-28 11:08 ` Dave Martin 2020-07-28 11:08 ` Dave Martin 2020-07-28 14:53 ` Szabolcs Nagy 2020-07-28 14:53 ` Szabolcs Nagy 2020-07-28 19:59 ` Catalin Marinas 2020-07-28 19:59 ` Catalin Marinas 2020-08-03 12:43 ` Szabolcs Nagy 2020-08-03 12:43 ` Szabolcs Nagy 2020-08-07 15:19 ` Catalin Marinas 2020-08-07 15:19 ` Catalin Marinas 2020-08-10 14:13 ` Szabolcs Nagy 2020-08-10 14:13 ` Szabolcs Nagy 2020-08-11 17:20 ` Catalin Marinas 2020-08-11 17:20 ` Catalin Marinas 2020-08-12 12:45 ` Szabolcs Nagy 2020-08-12 12:45 ` Szabolcs Nagy 2020-08-19 9:54 ` Catalin Marinas [this message] 2020-08-19 9:54 ` Catalin Marinas 2020-08-20 16:43 ` Szabolcs Nagy 2020-08-20 16:43 ` Szabolcs Nagy 2020-08-20 17:27 ` Paul Eggert 2020-08-20 17:27 ` Paul Eggert 2020-08-22 11:31 ` Catalin Marinas 2020-08-22 11:31 ` Catalin Marinas 2020-08-22 11:28 ` Catalin Marinas 2020-08-22 11:28 ` Catalin Marinas
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200819095453.GA86@DESKTOP-O1885NU.localdomain \ --to=catalin.marinas@arm.com \ --cc=Dave.Martin@arm.com \ --cc=akpm@linux-foundation.org \ --cc=andreyknvl@google.com \ --cc=kevin.brodsky@arm.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-mm@kvack.org \ --cc=nd@arm.com \ --cc=pcc@google.com \ --cc=szabolcs.nagy@arm.com \ --cc=vincenzo.frascino@arm.com \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.