All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suzuki.Poulose@arm.com (Suzuki K. Poulose)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/7] arm64: relax Image placement rules
Date: Fri, 25 Sep 2015 09:44:10 +0100	[thread overview]
Message-ID: <5605095A.10707@arm.com> (raw)
In-Reply-To: <CAKv+Gu-WGSaGA+4OJcNOct+sdBHsO8yKOc50t3jmB86xonWQ=g@mail.gmail.com>

On 25/09/15 00:19, Ard Biesheuvel wrote:
> On 24 September 2015 at 09:38, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> On 24 September 2015 at 09:37, Suzuki K. Poulose <Suzuki.Poulose@arm.com> wrote:
>>> On 23/09/15 01:37, Ard Biesheuvel wrote:


>>>
>>> Ard,
>>>
>>> I gave your series a quick run and dumping the kernel page tables(with
>>> CONFIG_ARM64_PTDUMP)
>>> I find this problem :
>>>
>>> ...
>>>
>>> ---[ Kernel Mapping ]---
>>> 0xffffffbffc000000-0xffffffbffc600000           6M     RW x  SHD AF
>>> MEM/NORMAL    *****
>>> 0xffffffbffc600000-0xffffffbffc7f5000        2004K     RW x  SHD AF    UXN
>>> MEM/NORMAL
>>> 0xffffffbffc7f5000-0xffffffbffc875000         512K     RW NX SHD AF    UXN
>>> MEM/NORMAL
>>> 0xffffffbffc875000-0xffffffbffca00000        1580K     RW x  SHD AF    UXN
>>> MEM/NORMAL
>>> ---[ Linear Mapping ]---
>>> 0xffffffc000000000-0xffffffc040000000           1G     RW NX SHD AF    UXN
>>> MEM/NORMAL
>>>
>>>
>>> Note that the first mapping in the kernel doesn't have UXN set, which is a
>>> regression.
>>> I haven't started digging into it yet, but I thought I will point it out
>>> here, in case you
>>> already fixed it.
>>>
>>
>> Ok, thanks for pointing that out. I will look into it.
>>
>
> Turns out that, since the kernel mapping is not overwritten by the
> linear mapping, it retains the original permissions assigned in
> head.S. So this is enough to fix it
>
> """
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 2df4a55f00d4..fcd250cff4bf 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -62,8 +62,8 @@
>   /*
>    * Initial memory map attributes.
>    */
> -#define PTE_FLAGS      PTE_TYPE_PAGE | PTE_AF | PTE_SHARED
> -#define PMD_FLAGS      PMD_TYPE_SECT | PMD_SECT_AF | PMD_SECT_S
> +#define PTE_FLAGS      PTE_TYPE_PAGE | PTE_AF | PTE_SHARED | PTE_UXN
> +#define PMD_FLAGS      PMD_TYPE_SECT | PMD_SECT_AF | PMD_SECT_S | PMD_SECT_UXN
>
>   #ifdef CONFIG_ARM64_64K_PAGES
>   #define MM_MMUFLAGS    PTE_ATTRINDX(MT_NORMAL) | PTE_FLAGS
> """
>

Yes, that fixes it. With that I get :

---[ Kernel Mapping ]---
0xffffffbffc000000-0xffffffbffc600000           6M     RW x  SHD AF    UXN MEM/NORMAL
0xffffffbffc600000-0xffffffbffc7f5000        2004K     RW x  SHD AF    UXN MEM/NORMAL
0xffffffbffc7f5000-0xffffffbffc875000         512K     RW NX SHD AF    UXN MEM/NORMAL
0xffffffbffc875000-0xffffffbffca00000        1580K     RW x  SHD AF    UXN MEM/NORMAL
---[ Linear Mapping ]---
0xffffffc000000000-0xffffffc080000000           2G     RW NX SHD AF    UXN MEM/NORMAL
0xffffffc800000000-0xffffffc880000000           2G     RW NX SHD AF    UXN MEM/NORMAL



>
>>> Note: I see that you have used CONFIG_ARM64_64K_PAGES to handle
>>> section/table mapping
>>> (which I have tried to cleanup in 16K page size series and which is not
>>> merged yet).
>>> We should be careful when we merge our patches, as we could miss such new
>>> cases.
>>>
>>
>> I was aware of this, and I think it makes sense to the 16 KB pages to
>> be merged first, and then I will rebase these patches on top of it.
>>
>
> Do you have a git tree with the latest version?
>

Yes, it is available here :

git://linux-arm.org/linux-skp.git  16k/v2-4.3-rc1


Thanks
Suzuki

  reply	other threads:[~2015-09-25  8:44 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-23  0:37 [PATCH v2 0/7] arm64: relax Image placement rules Ard Biesheuvel
2015-09-23  0:37 ` [PATCH v2 1/7] of/fdt: make memblock minimum physical address arch configurable Ard Biesheuvel
2015-09-23  4:45   ` Mark Rutland
2015-09-23 22:59   ` Rob Herring
2015-09-23  0:37 ` [PATCH v2 2/7] arm64: use more granular reservations for static page table allocations Ard Biesheuvel
2015-09-23  0:37 ` [PATCH v2 3/7] arm64: split off early mapping code from early_fixmap_init() Ard Biesheuvel
2015-09-23  0:37 ` [PATCH v2 4/7] arm64: mm: explicitly bootstrap the linear mapping Ard Biesheuvel
2015-09-23  0:37 ` [PATCH v2 5/7] arm64: move kernel mapping out of linear region Ard Biesheuvel
2015-09-23  0:37 ` [PATCH v2 6/7] arm64: map linear region as non-executable Ard Biesheuvel
2015-09-23  0:37 ` [PATCH v2 7/7] arm64: allow kernel Image to be loaded anywhere in physical memory Ard Biesheuvel
2015-10-14 11:30   ` James Morse
2015-10-14 13:25     ` Ard Biesheuvel
2015-10-14 16:34       ` Catalin Marinas
2015-10-14 16:51         ` Ard Biesheuvel
2015-10-15 10:04           ` James Morse
2015-09-24 16:37 ` [PATCH v2 0/7] arm64: relax Image placement rules Suzuki K. Poulose
2015-09-24 16:38   ` Ard Biesheuvel
2015-09-24 23:19     ` Ard Biesheuvel
2015-09-25  8:44       ` Suzuki K. Poulose [this message]
2015-09-25 21:53         ` Ard Biesheuvel
2015-10-13 17:07 ` Catalin Marinas
2015-10-13 17:14   ` Ard Biesheuvel

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=5605095A.10707@arm.com \
    --to=suzuki.poulose@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 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.