All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Yang Shi <yang@os.amperecomputing.com>
Cc: "Christoph Lameter (Ampere)" <cl@gentwo.org>,
	will@kernel.org, anshuman.khandual@arm.com, david@redhat.com,
	scott@os.amperecomputing.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [v5 PATCH] arm64: mm: force write fault for atomic RMW instructions
Date: Wed, 10 Jul 2024 10:22:28 +0100	[thread overview]
Message-ID: <Zo5S1JE8B912SHya@arm.com> (raw)
In-Reply-To: <cb0bd817-6948-4944-ab09-4ec2aba41cfa@os.amperecomputing.com>

On Tue, Jul 09, 2024 at 03:29:58PM -0700, Yang Shi wrote:
> On 7/9/24 11:35 AM, Catalin Marinas wrote:
> > On Tue, Jul 09, 2024 at 10:56:55AM -0700, Yang Shi wrote:
> > > On 7/4/24 3:03 AM, Catalin Marinas wrote:
> > > I tested exec-only on QEMU tcg, but I don't have a hardware supported EPAN.
> > > I don't think performance benchmark on QEMU tcg makes sense since it is
> > > quite slow, such small overhead is unlikely measurable on it.
> > 
> > Yeah, benchmarking under qemu is pointless. I think you can remove some
> > of the ARM64_HAS_EPAN checks (or replaced them with ARM64_HAS_PAN) just
> > for testing. For security reason, we removed this behaviour in commit
> > 24cecc377463 ("arm64: Revert support for execute-only user mappings")
> > but it's good enough for testing. This should give you PROT_EXEC-only
> > mappings on your hardware.
> 
> Thanks for the suggestion. IIUC, I still can emulate exec-only even though
> hardware doesn't support EPAN? So it means reading exec-only area in kernel
> still can trigger fault, right?

Yes, it's been supported since ARMv8.0. We limited it to EPAN only since
setting a PROT_EXEC mapping still allowed the kernel to access the
memory even if PSTATE.PAN was set.

> And 24cecc377463 ("arm64: Revert support for execute-only user mappings")
> can't be reverted cleanly by git revert, so I did it manually as below.

Yeah, I wasn't expecting that to work.

> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 6a8b71917e3b..0bdedd415e56 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -573,8 +573,8 @@ static int __kprobes do_page_fault(unsigned long far,
> unsigned long esr,
>                 /* Write implies read */
>                 vm_flags |= VM_WRITE;
>                 /* If EPAN is absent then exec implies read */
> -               if (!alternative_has_cap_unlikely(ARM64_HAS_EPAN))
> -                       vm_flags |= VM_EXEC;
> +               //if (!alternative_has_cap_unlikely(ARM64_HAS_EPAN))
> +               //      vm_flags |= VM_EXEC;
>         }
> 
>         if (is_ttbr0_addr(addr) && is_el1_permission_fault(addr, esr, regs))
> {
> diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
> index 642bdf908b22..d30265d424e4 100644
> --- a/arch/arm64/mm/mmap.c
> +++ b/arch/arm64/mm/mmap.c
> @@ -19,7 +19,7 @@ static pgprot_t protection_map[16] __ro_after_init = {
>         [VM_WRITE]                                      = PAGE_READONLY,
>         [VM_WRITE | VM_READ]                            = PAGE_READONLY,
>         /* PAGE_EXECONLY if Enhanced PAN */
> -       [VM_EXEC]                                       = PAGE_READONLY_EXEC,
> +       [VM_EXEC]                                       = PAGE_EXECONLY,
>         [VM_EXEC | VM_READ]                             = PAGE_READONLY_EXEC,
>         [VM_EXEC | VM_WRITE]                            = PAGE_READONLY_EXEC,
>         [VM_EXEC | VM_WRITE | VM_READ]                  = PAGE_READONLY_EXEC,

In theory you'd need to change the VM_SHARED | VM_EXEC entry as well.
Otherwise it looks fine.

-- 
Catalin


  reply	other threads:[~2024-07-10  9:23 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-26 19:18 [v5 PATCH] arm64: mm: force write fault for atomic RMW instructions Yang Shi
2024-06-28 16:54 ` Catalin Marinas
2024-06-28 16:57   ` Christoph Lameter (Ampere)
2024-06-28 17:24     ` Catalin Marinas
2024-06-28 18:20       ` Yang Shi
2024-07-01 19:43         ` Catalin Marinas
2024-07-02 10:26           ` Ryan Roberts
2024-07-02 11:22             ` David Hildenbrand
2024-07-02 12:36               ` Ryan Roberts
2024-07-02 12:58                 ` David Hildenbrand
2024-07-02 13:26                   ` Ryan Roberts
2024-07-02 13:50                     ` David Hildenbrand
2024-07-02 14:51                       ` Ryan Roberts
2024-07-15 13:09             ` Ryan Roberts
2024-07-02 22:21           ` Yang Shi
2024-07-04 10:03             ` Catalin Marinas
2024-07-05 17:05               ` Christoph Lameter (Ampere)
2024-07-05 18:24                 ` Catalin Marinas
2024-07-05 18:51                   ` Christoph Lameter (Ampere)
2024-07-06  9:47                     ` Catalin Marinas
2024-07-09 17:56               ` Yang Shi
2024-07-09 18:35                 ` Catalin Marinas
2024-07-09 22:29                   ` Yang Shi
2024-07-10  9:22                     ` Catalin Marinas [this message]
2024-07-10 18:43                       ` Yang Shi
2024-07-11 17:43                         ` Catalin Marinas
2024-07-11 18:17                           ` Yang Shi
2024-08-13 17:09                             ` Yang Shi
2024-08-21 10:18                             ` Catalin Marinas
2024-08-21 11:32                               ` Dev Jain
2024-08-23  9:59                               ` Will Deacon
2024-06-28 18:26       ` Christoph Lameter (Ampere)

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=Zo5S1JE8B912SHya@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=anshuman.khandual@arm.com \
    --cc=cl@gentwo.org \
    --cc=david@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=scott@os.amperecomputing.com \
    --cc=will@kernel.org \
    --cc=yang@os.amperecomputing.com \
    /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: link
Be 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.