From: Catalin Marinas <catalin.marinas@arm.com> To: Luis Machado <luis.machado@linaro.org> Cc: linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, Will Deacon <will@kernel.org>, Dave P Martin <Dave.Martin@arm.com>, Vincenzo Frascino <vincenzo.frascino@arm.com>, Szabolcs Nagy <szabolcs.nagy@arm.com>, Kevin Brodsky <kevin.brodsky@arm.com>, Andrey Konovalov <andreyknvl@google.com>, Peter Collingbourne <pcc@google.com>, Andrew Morton <akpm@linux-foundation.org>, Alan Hayward <Alan.Hayward@arm.com>, Omair Javaid <omair.javaid@linaro.org> Subject: Re: [PATCH v7 22/29] arm64: mte: ptrace: Add PTRACE_{PEEK,POKE}MTETAGS support Date: Sat, 22 Aug 2020 11:56:08 +0100 [thread overview] Message-ID: <20200822105607.GA16635@gaia> (raw) In-Reply-To: <95f0294b-93fb-bc5e-5ae5-fd3ada2dc7ce@linaro.org> Hi Luis, On Thu, Aug 13, 2020 at 11:01:06AM -0300, Luis Machado wrote: > There has been changes to GDB's/LLDB's side to incorporate a tag type into > the peek/poke requests. This is an attempt to anticipate required support > for other tag types, like CHERI's tags. Those are somewhat different from > MTE's tags. Please note that Morello (the ARM's CHERI implementation) won't go into mainline Linux for the time being. It's a development board to experiment with CHERI and the architecture may eventually turn out slightly different. Also note that the current Morello hardware doesn't support MTE. The tags are indeed different from the MTE ones, though both are just additional metadata associated with a set of bytes in memory. It happens that a tag in both cases corresponds to a 16-byte memory range. > The core file design for storing tags, which is in progress and currently in > my court, is also taking into account other types of tags. It makes sense for the core file. > Given the above, should we consider passing a type to the kernel ptrace > requests as well? > > Also, since the ptrace requests would have to handle different types of > tags, should we rename PEEKMTETAGS/POKEMTETAGS to PEEKTAGS/POKETAGS instead > and make those requests generic? I'm not sure how we could pass a type since ptrace() only takes a single argument for the request. We could use a different structure than iovec and encode a type in a field in the new structure but I'd rather keep the generic struct iovec. So basically the "MTE" part in PEEKMTETAGS is the type. Internally, the kernel implementation will probably translate the request into a common function call with a tag type but for the user-visible ptrace() interface, I don't see what benefits it would bring. If you have a better suggestion on how to encode the type, I'm open to discuss it. -- Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com> To: Luis Machado <luis.machado@linaro.org> Cc: linux-arch@vger.kernel.org, Omair Javaid <omair.javaid@linaro.org>, Szabolcs Nagy <szabolcs.nagy@arm.com>, Andrey Konovalov <andreyknvl@google.com>, Kevin Brodsky <kevin.brodsky@arm.com>, Peter Collingbourne <pcc@google.com>, linux-mm@kvack.org, Alan Hayward <Alan.Hayward@arm.com>, Andrew Morton <akpm@linux-foundation.org>, Vincenzo Frascino <vincenzo.frascino@arm.com>, Will Deacon <will@kernel.org>, Dave P Martin <Dave.Martin@arm.com>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v7 22/29] arm64: mte: ptrace: Add PTRACE_{PEEK,POKE}MTETAGS support Date: Sat, 22 Aug 2020 11:56:08 +0100 [thread overview] Message-ID: <20200822105607.GA16635@gaia> (raw) In-Reply-To: <95f0294b-93fb-bc5e-5ae5-fd3ada2dc7ce@linaro.org> Hi Luis, On Thu, Aug 13, 2020 at 11:01:06AM -0300, Luis Machado wrote: > There has been changes to GDB's/LLDB's side to incorporate a tag type into > the peek/poke requests. This is an attempt to anticipate required support > for other tag types, like CHERI's tags. Those are somewhat different from > MTE's tags. Please note that Morello (the ARM's CHERI implementation) won't go into mainline Linux for the time being. It's a development board to experiment with CHERI and the architecture may eventually turn out slightly different. Also note that the current Morello hardware doesn't support MTE. The tags are indeed different from the MTE ones, though both are just additional metadata associated with a set of bytes in memory. It happens that a tag in both cases corresponds to a 16-byte memory range. > The core file design for storing tags, which is in progress and currently in > my court, is also taking into account other types of tags. It makes sense for the core file. > Given the above, should we consider passing a type to the kernel ptrace > requests as well? > > Also, since the ptrace requests would have to handle different types of > tags, should we rename PEEKMTETAGS/POKEMTETAGS to PEEKTAGS/POKETAGS instead > and make those requests generic? I'm not sure how we could pass a type since ptrace() only takes a single argument for the request. We could use a different structure than iovec and encode a type in a field in the new structure but I'd rather keep the generic struct iovec. So basically the "MTE" part in PEEKMTETAGS is the type. Internally, the kernel implementation will probably translate the request into a common function call with a tag type but for the user-visible ptrace() interface, I don't see what benefits it would bring. If you have a better suggestion on how to encode the type, I'm open to discuss it. -- 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-22 10:56 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 [this message] 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 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=20200822105607.GA16635@gaia \ --to=catalin.marinas@arm.com \ --cc=Alan.Hayward@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=luis.machado@linaro.org \ --cc=omair.javaid@linaro.org \ --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.