[PATCH 2/2] arm64: mm: use XN table mapping attributes for the linear region

Ard Biesheuvel ardb at kernel.org
Fri Mar 5 19:17:07 GMT 2021


On Fri, 5 Mar 2021 at 20:06, Catalin Marinas <catalin.marinas at arm.com> wrote:
>
> On Thu, Mar 04, 2021 at 06:11:45PM +0100, Ard Biesheuvel wrote:
> > The way the arm64 kernel virtual address space is constructed guarantees
> > that swapper PGD entries are never shared between the linear region on
> > the one hand, and the vmalloc region on the other, which is where all
> > kernel text, module text and BPF text mappings reside.
> >
> > This means that mappings in the linear region (which never require
> > executable permissions) never share any table entries at any level with
> > mappings that do require executable permissions, and so we can set the
> > table-level PXN/UXN attributes for all table entries that are created
> > while setting up mappings in the linear region. Since swapper's PGD
> > level page table is mapped r/o itself, this adds another layer of
> > robustness to the way the kernel manages its own page tables.
>
> In ARMv8.1 the architecture added the possibility of disabling the
> hierarchical page table permissions (FEAT_HPDS) so that we can use these
> bits for software.
>

Sure, but I don't think there is a shortage of software bits in table
descriptors, right? And we don't enable the feature in the first
place.

> Is there any big advantage to using the hierarchical permissions vs
> some sanity check in set_pte() for example?
>

There is a big advantage: the fact that the permissions are both
hierarchical and subtractive.

Sanity checks in set_pte() only cover page mappings that were created
in the correct way. But that does not help us if an attacker manages a
single 64-bit write that creates a page or table entry pointing to a
page under their control. Taking away the exec permissions at the
levels above makes it much more difficult to carry out such an attack,
especially given that the root level is not mapped read-write to begin
with.



More information about the linux-arm-kernel mailing list