public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 4/5] arm64: mmu: map .text as read-only from the outset
Date: Tue, 14 Feb 2017 17:40:30 +0000	[thread overview]
Message-ID: <20170214174029.GJ23718@leverpostej> (raw)
In-Reply-To: <651D9CBB-3E64-41CE-BF85-D2FF0CB927B7@linaro.org>

On Tue, Feb 14, 2017 at 04:15:11PM +0000, Ard Biesheuvel wrote:
> 
> > On 14 Feb 2017, at 15:57, Mark Rutland <mark.rutland@arm.com> wrote:
> > 
> >> On Sat, Feb 11, 2017 at 08:23:05PM +0000, Ard Biesheuvel wrote:
> >> Now that alternatives patching code no longer relies on the primary
> >> mapping of .text being writable, we can remove the code that removes
> >> the writable permissions post-init time, and map it read-only from
> >> the outset.
> >> 
> >> Reviewed-by: Laura Abbott <labbott@redhat.com>
> >> Reviewed-by: Kees Cook <keescook@chromium.org>
> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > 
> > This generally looks good.
> > 
> > One effect of this is that even with rodata=off, external debuggers
> > can't install SW breakpoints via the executable mapping.
> 
> Interesting. For the sake of my education, could you elaborate on how
> that works under the hood?

There are details in ARM DDI 0487A.k_iss10775, Chapter H1, "About
External Debug", page H1-4839 onwards. Otherwise, executive summary
below.

An external debugger can place a CPU into debug state. This is
orthogonal to execution state and exception level, which are unchanged.
While in this state, the CPU (only) executes instructions fed to it by
the debugger through a special register.

To install a SW breakpoint, the debugger makes the CPU enter debug
state, then issues regular stores, barriers, and cache maintenance.
These operate in the current execution state at the current EL, using
the current translation regime.

The external debugger can also trap exceptions (e.g. those caused by the
SW breakpoint). The CPU enters debug state when these are trapped.

> > We might want to allow that to be overridden. e.g. make rodata= an
> > early param, and switch the permissions based on that in map_kernel(),
> > e.g. have:
> > 
> >    pgprot_t text_prot = rodata_enabled ? PAGE_KERNEL_ROX
> >                        : PAGE_KERNEL_EXEC);
> > 
> > ... and use that for .text and .init.text by default.
> > 
> > 
> 
> Is there any way we could restrict this privilege to external
> debuggers?

My understanding is that we cannot.

> Having trivial 'off' switches for security features makes me feel
> uneasy (although this is orthogonal to this patch)

>From my PoV, external debuggers are the sole reason to allow rodata=off
for arm64, and we already allow rodata=off.

Thanks,
Mark.

  reply	other threads:[~2017-02-14 17:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-11 20:23 [PATCH v2 0/5] arm64: mmu: avoid writeable-executable mappings Ard Biesheuvel
2017-02-11 20:23 ` [PATCH v2 1/5] arm: kvm: move kvm_vgic_global_state out of .text section Ard Biesheuvel
2017-02-11 20:23 ` [PATCH v2 2/5] arm64: mmu: move TLB maintenance from callers to create_mapping_late() Ard Biesheuvel
2017-02-14 15:54   ` Mark Rutland
2017-02-11 20:23 ` [PATCH v2 3/5] arm64: alternatives: apply boot time fixups via the linear mapping Ard Biesheuvel
2017-02-14 15:56   ` Mark Rutland
2017-02-11 20:23 ` [PATCH v2 4/5] arm64: mmu: map .text as read-only from the outset Ard Biesheuvel
2017-02-14 15:57   ` Mark Rutland
2017-02-14 16:15     ` Ard Biesheuvel
2017-02-14 17:40       ` Mark Rutland [this message]
2017-02-14 17:49         ` Ard Biesheuvel
2017-02-14 17:54           ` Mark Rutland
2017-02-11 20:23 ` [PATCH v2 5/5] arm64: mmu: apply strict permissions to .init.text and .init.data Ard Biesheuvel
2017-02-14 15:57   ` Mark Rutland

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=20170214174029.GJ23718@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox