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: Tue, 11 Aug 2020 18:20:38 +0100 [thread overview] Message-ID: <20200811172038.GB1429@gaia> (raw) In-Reply-To: <20200810141309.GK14398@arm.com> On Mon, Aug 10, 2020 at 03:13:09PM +0100, Szabolcs Nagy wrote: > The 08/07/2020 16:19, Catalin Marinas wrote: > > On Mon, Aug 03, 2020 at 01:43:10PM +0100, Szabolcs Nagy wrote: > > > if we can always turn sync tag checks on early whenever mte is > > > available then i think there is no issue. > > > > > > but if we have to make the decision later for compatibility or > > > performance reasons then per thread setting is problematic. > > > > At least for libc, I'm not sure how you could even turn MTE on at > > run-time. The heap allocations would have to be mapped with PROT_MTE as > > we can't easily change them (well, you could mprotect(), assuming the > > user doesn't use tagged pointers on them). > > e.g. dlopen of library with stack tagging. (libc can mark stacks with > PROT_MTE at that time) 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/ > or just turn on sync tag checks later when using heap tagging. I wonder whether setting the synchronous tag check mode by default would improve this aspect. This would not have any effect until PROT_MTE is used. If software wants some better performance they can explicitly opt in to asynchronous mode or disable tag checking after some SIGSEGV + reporting (this shouldn't exclude the environment variables you currently use for controlling the tag check mode). Also, if there are saner defaults for the user GCR_EL1.Excl (currently all masked), we should decide them now. If stack tagging will come with some ELF information, we could make the default tag checking and GCR_EL1.Excl choices based on that, otherwise maybe we should revisit the default configuration the kernel sets for the user in the absence of any other information. > > There is a case to switch tag checking from asynchronous to synchronous > > at run-time based on a signal but that's rather specific to Android > > where zygote controls the signal handler. I don't think you can do this > > with libc. Even on Android, since the async fault signal is delivered > > per thread, it probably does this lazily (alternatively, it could issue > > a SIGUSRx to the other threads for synchronisation). > > i think what that zygote is doing is a valid use-case but > in a normal linux setup the application owns the signal > handlers so the tag check switch has to be done by the > application. the libc can expose some api for it, so in > principle it's enough if the libc can do the runtime > switch, but we dont plan to add new libc apis for mte. Due to the synchronisation aspect especially regarding the stack tagging, I'm not sure the kernel alone can safely do this. Changing the tagged address syscall ABI across multiple threads should be safer (well, at least the relaxing part). But if we don't solve the other aspects I mentioned above, I don't think there is much point in only doing it for this. > > > - library code normally initializes per thread state on the first call > > > into the library from a given thread, but with mte, as soon as > > > memory / pointers are tagged in one thread, all threads are > > > affected: not performing checks in other threads is less secure (may > > > be ok) and it means incompatible syscall abi (not ok). so at least > > > PR_TAGGED_ADDR_ENABLE should have process wide setting for this > > > usage. > > > > My assumption with MTE is that the libc will initialise it when the > > library is loaded (something __attribute__((constructor))) and it's > > still in single-threaded mode. Does it wait until the first malloc() > > call? Also, is there such thing as a per-thread initialiser for a > > dynamic library (not sure it can be implemented in practice though)? > > there is no per thread initializer in an elf module. > (tls state is usually initialized lazily in threads > when necessary.) > > malloc calls can happen before the ctors of an LD_PRELOAD > library and threads can be created before both. > glibc runs ldpreload ctors after other library ctors. 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. -- 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: Tue, 11 Aug 2020 18:20:38 +0100 [thread overview] Message-ID: <20200811172038.GB1429@gaia> (raw) In-Reply-To: <20200810141309.GK14398@arm.com> On Mon, Aug 10, 2020 at 03:13:09PM +0100, Szabolcs Nagy wrote: > The 08/07/2020 16:19, Catalin Marinas wrote: > > On Mon, Aug 03, 2020 at 01:43:10PM +0100, Szabolcs Nagy wrote: > > > if we can always turn sync tag checks on early whenever mte is > > > available then i think there is no issue. > > > > > > but if we have to make the decision later for compatibility or > > > performance reasons then per thread setting is problematic. > > > > At least for libc, I'm not sure how you could even turn MTE on at > > run-time. The heap allocations would have to be mapped with PROT_MTE as > > we can't easily change them (well, you could mprotect(), assuming the > > user doesn't use tagged pointers on them). > > e.g. dlopen of library with stack tagging. (libc can mark stacks with > PROT_MTE at that time) 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/ > or just turn on sync tag checks later when using heap tagging. I wonder whether setting the synchronous tag check mode by default would improve this aspect. This would not have any effect until PROT_MTE is used. If software wants some better performance they can explicitly opt in to asynchronous mode or disable tag checking after some SIGSEGV + reporting (this shouldn't exclude the environment variables you currently use for controlling the tag check mode). Also, if there are saner defaults for the user GCR_EL1.Excl (currently all masked), we should decide them now. If stack tagging will come with some ELF information, we could make the default tag checking and GCR_EL1.Excl choices based on that, otherwise maybe we should revisit the default configuration the kernel sets for the user in the absence of any other information. > > There is a case to switch tag checking from asynchronous to synchronous > > at run-time based on a signal but that's rather specific to Android > > where zygote controls the signal handler. I don't think you can do this > > with libc. Even on Android, since the async fault signal is delivered > > per thread, it probably does this lazily (alternatively, it could issue > > a SIGUSRx to the other threads for synchronisation). > > i think what that zygote is doing is a valid use-case but > in a normal linux setup the application owns the signal > handlers so the tag check switch has to be done by the > application. the libc can expose some api for it, so in > principle it's enough if the libc can do the runtime > switch, but we dont plan to add new libc apis for mte. Due to the synchronisation aspect especially regarding the stack tagging, I'm not sure the kernel alone can safely do this. Changing the tagged address syscall ABI across multiple threads should be safer (well, at least the relaxing part). But if we don't solve the other aspects I mentioned above, I don't think there is much point in only doing it for this. > > > - library code normally initializes per thread state on the first call > > > into the library from a given thread, but with mte, as soon as > > > memory / pointers are tagged in one thread, all threads are > > > affected: not performing checks in other threads is less secure (may > > > be ok) and it means incompatible syscall abi (not ok). so at least > > > PR_TAGGED_ADDR_ENABLE should have process wide setting for this > > > usage. > > > > My assumption with MTE is that the libc will initialise it when the > > library is loaded (something __attribute__((constructor))) and it's > > still in single-threaded mode. Does it wait until the first malloc() > > call? Also, is there such thing as a per-thread initialiser for a > > dynamic library (not sure it can be implemented in practice though)? > > there is no per thread initializer in an elf module. > (tls state is usually initialized lazily in threads > when necessary.) > > malloc calls can happen before the ctors of an LD_PRELOAD > library and threads can be created before both. > glibc runs ldpreload ctors after other library ctors. 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. -- 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-11 17:20 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 [this message] 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 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=20200811172038.GB1429@gaia \ --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.