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, 28 Jul 2020 20:59:57 +0100 [thread overview] Message-ID: <20200728195957.GA31698@gaia> (raw) In-Reply-To: <20200728145350.GR7127@arm.com> On Tue, Jul 28, 2020 at 03:53:51PM +0100, Szabolcs Nagy wrote: > The 07/28/2020 12:08, Dave Martin wrote: > > On Mon, Jul 27, 2020 at 05:36:35PM +0100, Szabolcs Nagy wrote: > > > a solution is to introduce a flag like SECCOMP_FILTER_FLAG_TSYNC > > > that means the prctl is for all threads in the process not just > > > for the current one. however the exact semantics is not obvious > > > if there are inconsistent settings in different threads or user > > > code tries to use the prctl concurrently: first checking then > > > setting the mte state via separate prctl calls is racy. but if > > > the userspace contract for enabling mte limits who and when can > > > call the prctl then i think the simple sync flag approach works. > > > > > > (the sync flag should apply to all prctl settings: tagged addr > > > syscall abi, mte check fault mode, irg tag excludes. ideally it > > > would work for getting the process wide state and it would fail > > > in case of inconsistent settings.) > > > > If going down this route, perhaps we could have sets of settings: > > so for each setting we have a process-wide value and a per-thread > > value, with defines rules about how they combine. > > > > Since MTE is a debugging feature, we might be able to be less aggressive > > about synchronisation than in the SECCOMP case. > > separate process-wide and per-thread value > works for me and i expect most uses will > be process wide settings. The problem with the thread synchronisation is, unlike SECCOMP, that we need to update the SCTLR_EL1.TCF0 field across all the CPUs that may run threads of the current process. I haven't convinced myself that this is race-free without heavy locking. If we go for some heavy mechanism like stop_machine(), that opens the kernel to DoS attacks from user. Still investigating if something like membarrier() would be sufficient. SECCOMP gets away with this as it only needs to set some variable without IPI'ing the other CPUs. > i don't think mte is less of a security > feature than seccomp. Well, MTE is probabilistic, SECCOMP seems to be more precise ;). > if linux does not want to add a per process > setting then only libc will be able to opt-in > to mte and only at very early in the startup > process (before executing any user code that > may start threads). this is not out of question, > but i think it limits the usage and deployment > options. There is also the risk that we try to be too flexible at this stage without a real use-case. -- 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, 28 Jul 2020 20:59:57 +0100 [thread overview] Message-ID: <20200728195957.GA31698@gaia> (raw) In-Reply-To: <20200728145350.GR7127@arm.com> On Tue, Jul 28, 2020 at 03:53:51PM +0100, Szabolcs Nagy wrote: > The 07/28/2020 12:08, Dave Martin wrote: > > On Mon, Jul 27, 2020 at 05:36:35PM +0100, Szabolcs Nagy wrote: > > > a solution is to introduce a flag like SECCOMP_FILTER_FLAG_TSYNC > > > that means the prctl is for all threads in the process not just > > > for the current one. however the exact semantics is not obvious > > > if there are inconsistent settings in different threads or user > > > code tries to use the prctl concurrently: first checking then > > > setting the mte state via separate prctl calls is racy. but if > > > the userspace contract for enabling mte limits who and when can > > > call the prctl then i think the simple sync flag approach works. > > > > > > (the sync flag should apply to all prctl settings: tagged addr > > > syscall abi, mte check fault mode, irg tag excludes. ideally it > > > would work for getting the process wide state and it would fail > > > in case of inconsistent settings.) > > > > If going down this route, perhaps we could have sets of settings: > > so for each setting we have a process-wide value and a per-thread > > value, with defines rules about how they combine. > > > > Since MTE is a debugging feature, we might be able to be less aggressive > > about synchronisation than in the SECCOMP case. > > separate process-wide and per-thread value > works for me and i expect most uses will > be process wide settings. The problem with the thread synchronisation is, unlike SECCOMP, that we need to update the SCTLR_EL1.TCF0 field across all the CPUs that may run threads of the current process. I haven't convinced myself that this is race-free without heavy locking. If we go for some heavy mechanism like stop_machine(), that opens the kernel to DoS attacks from user. Still investigating if something like membarrier() would be sufficient. SECCOMP gets away with this as it only needs to set some variable without IPI'ing the other CPUs. > i don't think mte is less of a security > feature than seccomp. Well, MTE is probabilistic, SECCOMP seems to be more precise ;). > if linux does not want to add a per process > setting then only libc will be able to opt-in > to mte and only at very early in the startup > process (before executing any user code that > may start threads). this is not out of question, > but i think it limits the usage and deployment > options. There is also the risk that we try to be too flexible at this stage without a real use-case. -- 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-07-28 20:00 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 [this message] 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 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=20200728195957.GA31698@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.