[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 14 Feb 2017 17:49:19 +0000
From: Ard Biesheuvel <ard.biesheuvel@...aro.org>
To: Mark Rutland <mark.rutland@....com>
Cc: linux-arm-kernel@...ts.infradead.org, catalin.marinas@....com,
will.deacon@....com, labbott@...oraproject.org, kvmarm@...ts.cs.columbia.edu,
marc.zyngier@....com, andre.przywara@....com, Suzuki.Poulose@....com,
james.morse@....com, keescook@...omium.org,
kernel-hardening@...ts.openwall.com, nd@....com
Subject: Re: [PATCH v2 4/5] arm64: mmu: map .text as read-only from the outset
> On 14 Feb 2017, at 17:40, Mark Rutland <mark.rutland@....com> wrote:
>
>> On Tue, Feb 14, 2017 at 04:15:11PM +0000, Ard Biesheuvel wrote:
>>
>>>> On 14 Feb 2017, at 15:57, Mark Rutland <mark.rutland@....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@...hat.com>
>>>> Reviewed-by: Kees Cook <keescook@...omium.org>
>>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@...aro.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.
>
OK, thanks for the explanation
>>> 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.
>
>
Indeed. If that is how it works currently, we shouldn't interfere with it. If we ever get anywhere with the lockdown patches, we should blacklist this parameter (or rather, not whitelist it, since blacklisting kernel params to enforce security is infeasible imo)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
