[PATCH v2 10/10] ARM: software-based priviledged-no-access support
will.deacon at arm.com
Fri Oct 9 03:53:09 PDT 2015
On Fri, Oct 09, 2015 at 10:28:14AM +0200, Linus Walleij wrote:
> On Tue, Aug 25, 2015 at 5:42 PM, Russell King
> <rmk+kernel at arm.linux.org.uk> wrote:
> > Provide a software-based implementation of the priviledged no access
> > support found in ARMv8.1.
> > Userspace pages are mapped using a different domain number from the
> > kernel and IO mappings. If we switch the user domain to "no access"
> > when we enter the kernel, we can prevent the kernel from touching
> > userspace.
> > However, the kernel needs to be able to access userspace via the
> > various user accessor functions. With the wrapping in the previous
> > patch, we can temporarily enable access when the kernel needs user
> > access, and re-disable it afterwards.
> > This allows us to trap non-intended accesses to userspace, eg, caused
> > by an inadvertent dereference of the LIST_POISON* values, which, with
> > appropriate user mappings setup, can be made to succeed. This in turn
> > can allow use-after-free bugs to be further exploited than would
> > otherwise be possible.
> > Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
> For some reason this patch explodes on my ARM PB11MPCore, it
> is a weird beast and corner case machine so I guess that is why
> it wasn't noticed. This happens a bit into the boot when freeing
> unused pages:
> Freeing unused kernel memory: 2672K (c0448000 - c06e4000)
> Unable to handle kernel paging request at virtual address b6f069f4
> pgd = c6e58000
> [b6f069f4] *pgd=76e09831, *pte=77ff759f, *ppte=77ff7e6e
> Internal error: Oops: 17 [#1] SMP ARM
> Modules linked in:
> CPU: 2 PID: 1 Comm: init Not tainted 4.3.0-rc4-00015-gf6702681a0af #48
> Hardware name: ARM-RealView PB11MPCore
> task: c7827bc0 ti: c782c000 task.ti: c782c000
> PC is at v6wbi_flush_user_tlb_range+0x28/0x48
> LR is at on_each_cpu_mask+0x58/0x60
> pc : [<c001abf0>] lr : [<c007c18c>] psr: 20000093
> sp : c782deb8 ip : 00000000 fp : 00000000
> r10: c6e5adc8 r9 : 00000001 r8 : b6f02000
> r7 : c7a17180 r6 : c782ded4 r5 : c0015118 r4 : 20000013
> r3 : 00000002 r2 : 00100075 r1 : b6f02000 r0 : b6f01002
> Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
> Control: 00c5787d Table: 76e5800a DAC: 00000051
It looks like we're faulting on the TLBI instruction, because it's
targetting a userspace address (r0 == 0xb6f01002) and the DAC prohibits
access to userspace. It's weird that this only seems to happen on 11MPCore
though; if this core was one of the guys getting cross-called, then I
could understand the bug, but the lr suggests that CPU 2 is initiating
the flush, so I'd expect the same problem to appear on any ARMv6 part.
Russell, have you tried the s/w PAN stuff on any v6 CPUs?
More information about the linux-arm-kernel