All of lore.kernel.org
 help / color / mirror / Atom feed
From: lauraa@codeaurora.org (Laura Abbott)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv4 7/7] arm64: add better page protections to arm64
Date: Thu, 30 Oct 2014 10:17:37 -0700	[thread overview]
Message-ID: <545272B1.7080702@codeaurora.org> (raw)
In-Reply-To: <20141028142040.GH9796@leverpostej>

On 10/28/2014 7:20 AM, Mark Rutland wrote:
> [resending due to previous header destruction]
>
> Hi Laura,
>
> On Mon, Oct 27, 2014 at 08:12:32PM +0000, Laura Abbott wrote:
>> Add page protections for arm64 similar to those in arm.
>> This is for security reasons to prevent certain classes
>> of exploits. The current method:
>>
>> - Map all memory as either RWX or RW. We round to the nearest
>>    section to avoid creating page tables before everything is mapped
>> - Once everything is mapped, if either end of the RWX section should
>>    not be X, we split the PMD and remap as necessary
>> - When initmem is to be freed, we change the permissions back to
>>    RW (using stop machine if necessary to flush the TLB)
>> - If CONFIG_DEBUG_RODATA is set, the read only sections are set
>>    read only.
>>
>> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
>> ---
>> v4: Combined the Kconfig options
>> ---
>>   arch/arm64/Kconfig.debug            |  23 +++
>>   arch/arm64/include/asm/cacheflush.h |   4 +
>>   arch/arm64/kernel/vmlinux.lds.S     |  17 ++
>>   arch/arm64/mm/init.c                |   1 +
>>   arch/arm64/mm/mm.h                  |   2 +
>>   arch/arm64/mm/mmu.c                 | 303 +++++++++++++++++++++++++++++++-----
>>   6 files changed, 314 insertions(+), 36 deletions(-)
>
> With this patch applied to v3.18-rc2, my board to blows up at boot when
> using UEFI (without DEBUG_RODATA selected):
>
> ---->8----
> EFI stub: Booting Linux Kernel...
> Initializing cgroup subsys cpu
> Linux version 3.18.0-rc2+ (mark at leverpostej) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #112 SMP PREEMPT Tue Oct 28 13:58:41 GMT 2014
> CPU: AArch64 Processor [410fd030] revision 0
> Detected VIPT I-cache on CPU0
> bootconsole [uart0] enabled
> efi: Getting EFI parameters from FDT:
> EFI v2.40 by ARM Juno EFI Oct  7 2014 15:05:42
> efi:  ACPI=0xfebdc000  ACPI 2.0=0xfebdc014
> cma: Reserved 16 MiB at fd800000
> BUG: failure at arch/arm64/mm/mmu.c:234/alloc_init_pmd()!
> Kernel panic - not syncing: BUG!
> CPU: 0 PID: 0 Comm: swapper Not tainted 3.18.0-rc2+ #112
> Call trace:
> [<ffffffc000087ec8>] dump_backtrace+0x0/0x124
> [<ffffffc000087ffc>] show_stack+0x10/0x1c
> [<ffffffc0004ebd58>] dump_stack+0x74/0xb8
> [<ffffffc0004eb018>] panic+0xe0/0x220
> [<ffffffc0004e8e08>] alloc_init_pmd+0x1cc/0x1dc
> [<ffffffc0004e8e3c>] alloc_init_pud+0x24/0x6c
> [<ffffffc0004e8f54>] __create_mapping+0xd0/0xf0
> [<ffffffc00069a0a0>] create_id_mapping+0x5c/0x68
> [<ffffffc00069964c>] efi_idmap_init+0x54/0xd8
> [<ffffffc0006978a8>] setup_arch+0x408/0x5c0
> [<ffffffc00069566c>] start_kernel+0x94/0x3a0
> ---[ end Kernel panic - not syncing: BUG!
> ---->8----
>
> I've not yet figured out precisely why. I haven't tried a !EFI boot
> because of the way my board is set up at the moment.
>

I think it's because the idmap is now being created earlier than
expected so it's trying to get memory from the normal allocator
and dying. I'll have to see if I can get my hands on an EFI
board and test it out.

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

  reply	other threads:[~2014-10-30 17:17 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1414440752-9411-1-git-send-email-lauraa@codeaurora.org>
2014-10-27 20:12 ` [PATCHv4 1/7] arm64: Treat handle_arch_irq as a function pointer Laura Abbott
2014-10-28  8:11   ` Ard Biesheuvel
2014-10-28 10:25   ` Mark Rutland
2014-10-27 20:12 ` [PATCHv4 2/7] arm64: Switch to ldr for loading the stub vectors Laura Abbott
2014-10-28  8:23   ` Ard Biesheuvel
2014-10-28  9:51   ` Marc Zyngier
2014-10-28 10:27   ` Mark Rutland
2014-10-27 20:12 ` [PATCHv4 3/7] arm64: Move cpu_resume into the text section Laura Abbott
2014-10-28  8:10   ` Ard Biesheuvel
2014-10-28  8:22     ` Ard Biesheuvel
2014-10-28 12:43       ` Mark Rutland
2014-10-28 15:26         ` Lorenzo Pieralisi
2014-10-28 15:31           ` Mark Rutland
2014-10-30 16:49             ` Laura Abbott
2014-10-27 20:12 ` [PATCHv4 4/7] arm64: Move some head.text functions to executable section Laura Abbott
2014-10-28  8:35   ` Ard Biesheuvel
2014-10-28 11:10     ` Mark Rutland
2014-10-30 17:06       ` Laura Abbott
2014-10-30 18:45         ` Mark Rutland
2014-10-27 20:12 ` [PATCHv4 5/7] arm64: Factor out fixmap initialiation from ioremap Laura Abbott
2014-10-28 14:17   ` Mark Rutland
2014-10-27 20:12 ` [PATCHv4 6/7] arm64: use fixmap for text patching when text is RO Laura Abbott
2014-10-27 20:12 ` [PATCHv4 7/7] arm64: add better page protections to arm64 Laura Abbott
2014-10-28 11:29   ` Steve Capper
2014-10-28 11:44     ` Ard Biesheuvel
2014-10-28 13:40       ` Steve Capper
2014-10-30 17:12     ` Laura Abbott
2014-10-28 14:20   ` Mark Rutland
2014-10-30 17:17     ` Laura Abbott [this message]
2014-10-27 20:19 ` [PATCHv4 0/7] Better page protections for arm64 Laura Abbott

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=545272B1.7080702@codeaurora.org \
    --to=lauraa@codeaurora.org \
    --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 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.