> From: Dale Rahn
> Date: Mon, 17 Aug 2020 18:33:29 -0500
>
> could we check that there is not an ESR value that indicates PAN violation
> instead of using 'instruction recognition'?
Doesn't exist unfortunately. You get a protection fault, but you get
the same protection fault if you try to
could we check that there is not an ESR value that indicates PAN violation
instead of using 'instruction recognition'?
Seems that it would be more reliable.
Thanks
Dale
On Mon, Aug 17, 2020 at 1:30 AM Jonathan Gray wrote:
> On Sat, Aug 15, 2020 at 01:54:34PM +0200, Mark Kettenis wrote:
> > >
On Sat, Aug 15, 2020 at 01:54:34PM +0200, Mark Kettenis wrote:
> > Date: Sat, 15 Aug 2020 20:21:09 +1000
> > From: Jonathan Gray
> >
> > On Fri, Aug 14, 2020 at 11:06:59PM +0200, Mark Kettenis wrote:
> > > > Date: Fri, 14 Aug 2020 14:40:23 +0200 (CEST)
> > > > From: Mark Kettenis
> > > >
> > >
Enabling PAN is a great idea. I have only skimmed this diff at this point,
but it looks reasonable, with the additional check to catch the PAN
violation in the data abort handler.
Dale
On Sat, Aug 15, 2020 at 6:56 AM Mark Kettenis
wrote:
> > Date: Sat, 15 Aug 2020 20:21:09 +1000
> > From:
> Date: Sat, 15 Aug 2020 20:21:09 +1000
> From: Jonathan Gray
>
> On Fri, Aug 14, 2020 at 11:06:59PM +0200, Mark Kettenis wrote:
> > > Date: Fri, 14 Aug 2020 14:40:23 +0200 (CEST)
> > > From: Mark Kettenis
> > >
> > > I suppose a way to test this properly is to pick a system call and
> > >
On Fri, Aug 14, 2020 at 11:06:59PM +0200, Mark Kettenis wrote:
> > Date: Fri, 14 Aug 2020 14:40:23 +0200 (CEST)
> > From: Mark Kettenis
> >
> > I suppose a way to test this properly is to pick a system call and
> > replace a copyin() with a direct access? That will succeed without
> > PAN but
> Date: Fri, 14 Aug 2020 14:40:23 +0200 (CEST)
> From: Mark Kettenis
>
> I suppose a way to test this properly is to pick a system call and
> replace a copyin() with a direct access? That will succeed without
> PAN but should fail with PAN enabled right?
So that does indeed work. However, the
> Date: Fri, 14 Aug 2020 12:29:51 +1000
> From: Jonathan Gray
>
> On Thu, Aug 13, 2020 at 09:17:41PM +0200, Mark Kettenis wrote:
> > ARMv8.1 introduced PAN (Priviliged Access Never) which prevents the
> > kernel from accessing userland data. This can be bypassed by using
> > special
On Thu, Aug 13, 2020 at 09:17:41PM +0200, Mark Kettenis wrote:
> ARMv8.1 introduced PAN (Priviliged Access Never) which prevents the
> kernel from accessing userland data. This can be bypassed by using
> special instructions which we already use in copyin(9) and friends.
> So we can simply turn
> Date: Thu, 13 Aug 2020 22:52:57 +0200
> From: Patrick Wildt
>
> On Thu, Aug 13, 2020 at 09:17:41PM +0200, Mark Kettenis wrote:
> > ARMv8.1 introduced PAN (Priviliged Access Never) which prevents the
> > kernel from accessing userland data. This can be bypassed by using
> > special
On Thu, Aug 13, 2020 at 09:17:41PM +0200, Mark Kettenis wrote:
> ARMv8.1 introduced PAN (Priviliged Access Never) which prevents the
> kernel from accessing userland data. This can be bypassed by using
> special instructions which we already use in copyin(9) and friends.
> So we can simply turn
ARMv8.1 introduced PAN (Priviliged Access Never) which prevents the
kernel from accessing userland data. This can be bypassed by using
special instructions which we already use in copyin(9) and friends.
So we can simply turn this feature on if the CPU supports it.
Tested on an Odroid-C4 which
12 matches
Mail list logo
