kernel virtual memory access (from app) does not generate segfault

kernel virtual memory access (from app) does not generate segfault

[Sasha Sirotkin]

More specifically, writing from usermode application to a kernel virtual 
memory address on ARM does  result in segmentation fault, however 
calling a function in this memory region for some reason does not.

For instance, this code generates a segfault allright

int * aa;
aa = 0xc0000000;
*aa=42;

However this code does not, instead the process simply hangs (and can be 
killed)

void (*func)(void);
func = 0xc0000000;
func();

I stumbled across this by accident. Just curious to understand why it 
happens. Isn't it a bug ?


P.S. My kernel is 2.6.32.7 and the CPU is ARM926EJ-S rev 5 (v5l)

kernel virtual memory access (from app) does not generate segfault

[Ben Dooks]

On Tue, Apr 20, 2010 at 12:14:30PM +0300, Sasha Sirotkin wrote:
> More specifically, writing from usermode application to a kernel virtual  
> memory address on ARM does  result in segmentation fault, however  
> calling a function in this memory region for some reason does not.
>
> For instance, this code generates a segfault allright
>
> int * aa;
> aa = 0xc0000000;
> *aa=42;
>
> However this code does not, instead the process simply hangs (and can be  
> killed)
>
> void (*func)(void);
> func = 0xc0000000;
> func();

Your first example writes to an area, your second is execution. IIRC,
this version of the ARM architecture equates read and execute permission
and so you may actually have permission to read this area and thus execute
code in it.

> I stumbled across this by accident. Just curious to understand why it  
> happens. Isn't it a bug ?

Don't think so, other than you might not want that area to be readable
by user space?

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

kernel virtual memory access (from app) does not generate segfault

[Dave P. Martin]

 

> -----Original Message-----
> From: linux-arm-kernel-bounces at lists.infradead.org 
> [mailto:linux-arm-kernel-bounces at lists.infradead.org] On 
> Behalf Of Ben Dooks
> Sent: 20 April 2010 10:35
> To: Sasha Sirotkin
> Cc: linux-arm-kernel at lists.infradead.org
> Subject: Re: kernel virtual memory access (from app) does not 

[..]

> > For instance, this code generates a segfault allright
> >
> > int * aa;
> > aa = 0xc0000000;
> > *aa=42;
> >
> > However this code does not, instead the process simply 
> hangs (and can 
> > be
> > killed)
> >
> > void (*func)(void);
> > func = 0xc0000000;
> > func();
> 
> Your first example writes to an area, your second is 
> execution. IIRC, this version of the ARM architecture equates 
> read and execute permission and so you may actually have 
> permission to read this area and thus execute code in it.
> 
> > I stumbled across this by accident. Just curious to 
> understand why it 
> > happens. Isn't it a bug ?
> 
> Don't think so, other than you might not want that area to be 
> readable by user space?

I tried reading that address (albeit on an old 2.6.28 kernel), and I get a
segfault.

Trying to execute in kernel space is the only thing that appears to hang.
Attaching to the process in gdb, I observed that pc is always 0xc0000000
when the process is stopped.

top accounts most of the CPU time as being consumed in the kernel.

I think what is going on here is that the kernel is catching the expected
prefetch abort, but the handler fails to send SIGSEGV to the user process
--- the process is resumed with the same pc and we end up in an endless
spin.

This only appears to apply to certain address ranges: substituting some
other random unmapped address for 0xc0000000 (0x48000000 worked for me), we
get the expected segfault.

Does the prefetch abort handler assume that lr >= 0xc0000000 implies the
fault came from inside the kernel?  Should it?

arch/arm/mm/fault.c has:

/* 
...
 * If the address is in kernel space (>= TASK_SIZE), then we are
 * probably faulting in the vmalloc() area.
...
*/
static int __kprobes
do_translation_fault(unsigned long addr, unsigned int fsr,
                     struct pt_regs *regs)
{
...
        if (addr < TASK_SIZE)
                return do_page_fault(addr, fsr, regs);

So the common case for userspace prefetch aborts is do_page_fault()

This suggests that the weirdness is caused by something in the remainder of
do_translation_fault(), or something it calls.


The comment preceding do_translation_fault() suggests a possible unsafe
assumption which could lead to a security hole... but it really depends on
what the handler code is trying to do.  Unfortunately, my understanding has
broken down by this point.

Is someone else able to comment on how this code responds to a user fault >=
TASK_SIZE?

Cheers
---Dave

kernel virtual memory access (from app) does not generate segfault

[anfei]

On Tue, Apr 20, 2010 at 11:27:40AM +0100, Dave P. Martin wrote:
>  
> 
> > -----Original Message-----
> > From: linux-arm-kernel-bounces at lists.infradead.org 
> > [mailto:linux-arm-kernel-bounces at lists.infradead.org] On 
> > Behalf Of Ben Dooks
> > Sent: 20 April 2010 10:35
> > To: Sasha Sirotkin
> > Cc: linux-arm-kernel at lists.infradead.org
> > Subject: Re: kernel virtual memory access (from app) does not 
> 
> [..]
> 
> > > For instance, this code generates a segfault allright
> > >
> > > int * aa;
> > > aa = 0xc0000000;
> > > *aa=42;
> > >
> > > However this code does not, instead the process simply 
> > hangs (and can 
> > > be
> > > killed)
> > >
> > > void (*func)(void);
> > > func = 0xc0000000;
> > > func();
> > 
> > Your first example writes to an area, your second is 
> > execution. IIRC, this version of the ARM architecture equates 
> > read and execute permission and so you may actually have 
> > permission to read this area and thus execute code in it.
> > 
> > > I stumbled across this by accident. Just curious to 
> > understand why it 
> > > happens. Isn't it a bug ?
> > 
> > Don't think so, other than you might not want that area to be 
> > readable by user space?
> 
> I tried reading that address (albeit on an old 2.6.28 kernel), and I get a
> segfault.
> 
> Trying to execute in kernel space is the only thing that appears to hang.
> Attaching to the process in gdb, I observed that pc is always 0xc0000000
> when the process is stopped.
> 
> top accounts most of the CPU time as being consumed in the kernel.
> 
> I think what is going on here is that the kernel is catching the expected
> prefetch abort, but the handler fails to send SIGSEGV to the user process
> --- the process is resumed with the same pc and we end up in an endless
> spin.
> 
> This only appears to apply to certain address ranges: substituting some
> other random unmapped address for 0xc0000000 (0x48000000 worked for me), we
> get the expected segfault.
> 
> Does the prefetch abort handler assume that lr >= 0xc0000000 implies the
> fault came from inside the kernel?  Should it?
> 
> arch/arm/mm/fault.c has:
> 
> /* 
> ...
>  * If the address is in kernel space (>= TASK_SIZE), then we are
>  * probably faulting in the vmalloc() area.
> ...
> */
> static int __kprobes
> do_translation_fault(unsigned long addr, unsigned int fsr,
>                      struct pt_regs *regs)
> {
> ...
>         if (addr < TASK_SIZE)
>                 return do_page_fault(addr, fsr, regs);
> 
> So the common case for userspace prefetch aborts is do_page_fault()
> 
> This suggests that the weirdness is caused by something in the remainder of
> do_translation_fault(), or something it calls.
> 
> 
> The comment preceding do_translation_fault() suggests a possible unsafe
> assumption which could lead to a security hole... but it really depends on
> what the handler code is trying to do.  Unfortunately, my understanding has
> broken down by this point.
> 
> Is someone else able to comment on how this code responds to a user fault >=
> TASK_SIZE?
> 
I think something like this is needed:

diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 9d40c34..cd4d15c 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -393,6 +393,9 @@ do_translation_fault(unsigned long addr, unsigned int fsr,
 	if (addr < TASK_SIZE)
 		return do_page_fault(addr, fsr, regs);
 
+	if (user_mode(regs) && addr >= TASK_SIZE)
+		goto bad_area;
+
 	index = pgd_index(addr);
 
 	/*

Cheers,
Anfei.

> Cheers
> ---Dave
> 
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

kernel virtual memory access (from app) does not generate segfault

[Ben Dooks]

On Tue, Apr 20, 2010 at 10:20:47PM +0800, anfei wrote:
> On Tue, Apr 20, 2010 at 11:27:40AM +0100, Dave P. Martin wrote:
> >  
> > 
> > > -----Original Message-----
> > > From: linux-arm-kernel-bounces at lists.infradead.org 
> > > [mailto:linux-arm-kernel-bounces at lists.infradead.org] On 
> > > Behalf Of Ben Dooks
> > > Sent: 20 April 2010 10:35
> > > To: Sasha Sirotkin
> > > Cc: linux-arm-kernel at lists.infradead.org
> > > Subject: Re: kernel virtual memory access (from app) does not 
> > 
> > [..]
> > 
> > > > For instance, this code generates a segfault allright
> > > >
> > > > int * aa;
> > > > aa = 0xc0000000;
> > > > *aa=42;
> > > >
> > > > However this code does not, instead the process simply 
> > > hangs (and can 
> > > > be
> > > > killed)
> > > >
> > > > void (*func)(void);
> > > > func = 0xc0000000;
> > > > func();
> > > 
> > > Your first example writes to an area, your second is 
> > > execution. IIRC, this version of the ARM architecture equates 
> > > read and execute permission and so you may actually have 
> > > permission to read this area and thus execute code in it.
> > > 
> > > > I stumbled across this by accident. Just curious to 
> > > understand why it 
> > > > happens. Isn't it a bug ?
> > > 
> > > Don't think so, other than you might not want that area to be 
> > > readable by user space?
> > 
> > I tried reading that address (albeit on an old 2.6.28 kernel), and I get a
> > segfault.
> > 
> > Trying to execute in kernel space is the only thing that appears to hang.
> > Attaching to the process in gdb, I observed that pc is always 0xc0000000
> > when the process is stopped.
> > 
> > top accounts most of the CPU time as being consumed in the kernel.
> > 
> > I think what is going on here is that the kernel is catching the expected
> > prefetch abort, but the handler fails to send SIGSEGV to the user process
> > --- the process is resumed with the same pc and we end up in an endless
> > spin.
> > 
> > This only appears to apply to certain address ranges: substituting some
> > other random unmapped address for 0xc0000000 (0x48000000 worked for me), we
> > get the expected segfault.
> > 
> > Does the prefetch abort handler assume that lr >= 0xc0000000 implies the
> > fault came from inside the kernel?  Should it?
> > 
> > arch/arm/mm/fault.c has:
> > 
> > /* 
> > ...
> >  * If the address is in kernel space (>= TASK_SIZE), then we are
> >  * probably faulting in the vmalloc() area.
> > ...
> > */
> > static int __kprobes
> > do_translation_fault(unsigned long addr, unsigned int fsr,
> >                      struct pt_regs *regs)
> > {
> > ...
> >         if (addr < TASK_SIZE)
> >                 return do_page_fault(addr, fsr, regs);
> > 
> > So the common case for userspace prefetch aborts is do_page_fault()
> > 
> > This suggests that the weirdness is caused by something in the remainder of
> > do_translation_fault(), or something it calls.
> > 
> > 
> > The comment preceding do_translation_fault() suggests a possible unsafe
> > assumption which could lead to a security hole... but it really depends on
> > what the handler code is trying to do.  Unfortunately, my understanding has
> > broken down by this point.
> > 
> > Is someone else able to comment on how this code responds to a user fault >=
> > TASK_SIZE?
> > 
> I think something like this is needed:
> 
> diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> index 9d40c34..cd4d15c 100644
> --- a/arch/arm/mm/fault.c
> +++ b/arch/arm/mm/fault.c
> @@ -393,6 +393,9 @@ do_translation_fault(unsigned long addr, unsigned int fsr,
>  	if (addr < TASK_SIZE)
>  		return do_page_fault(addr, fsr, regs);
>  
> +	if (user_mode(regs) && addr >= TASK_SIZE)
> +		goto bad_area;
> +

technically, addr >= TASK_SIZE was guaranteed by the previous test
on addr. The user_mode(regs) may well be a good idea, although I'm
not sure if we get entered here if the kernel is attempting to access
user-mode memory by forcing unpriveldged accesses.

probably best to get Russell's opinion.

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

kernel virtual memory access (from app) does not generate segfault

[Russell King - ARM Linux]

On Tue, Apr 20, 2010 at 06:09:44PM +0100, Ben Dooks wrote:
> On Tue, Apr 20, 2010 at 10:20:47PM +0800, anfei wrote:
> > On Tue, Apr 20, 2010 at 11:27:40AM +0100, Dave P. Martin wrote:
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: linux-arm-kernel-bounces at lists.infradead.org 
> > > > [mailto:linux-arm-kernel-bounces at lists.infradead.org] On 
> > > > Behalf Of Ben Dooks
> > > > Sent: 20 April 2010 10:35
> > > > To: Sasha Sirotkin
> > > > Cc: linux-arm-kernel at lists.infradead.org
> > > > Subject: Re: kernel virtual memory access (from app) does not 
> > > 
> > > [..]
> > > 
> > > > > For instance, this code generates a segfault allright
> > > > >
> > > > > int * aa;
> > > > > aa = 0xc0000000;
> > > > > *aa=42;
> > > > >
> > > > > However this code does not, instead the process simply 
> > > > hangs (and can 
> > > > > be
> > > > > killed)
> > > > >
> > > > > void (*func)(void);
> > > > > func = 0xc0000000;
> > > > > func();
> > > > 
> > > > Your first example writes to an area, your second is 
> > > > execution. IIRC, this version of the ARM architecture equates 
> > > > read and execute permission and so you may actually have 
> > > > permission to read this area and thus execute code in it.

User programs do not have permission to read kernel addresses.  Trying to
do so _should_ generate a permission fault.

> > > I tried reading that address (albeit on an old 2.6.28 kernel), and I get a
> > > segfault.

... which is correct behaviour.

> > > Trying to execute in kernel space is the only thing that appears to hang.
> > > Attaching to the process in gdb, I observed that pc is always 0xc0000000
> > > when the process is stopped.
> > > 
> > > top accounts most of the CPU time as being consumed in the kernel.
> > > 
> > > I think what is going on here is that the kernel is catching the expected
> > > prefetch abort, but the handler fails to send SIGSEGV to the user process
> > > --- the process is resumed with the same pc and we end up in an endless
> > > spin.

Yes, that'd make sense.

> > diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> > index 9d40c34..cd4d15c 100644
> > --- a/arch/arm/mm/fault.c
> > +++ b/arch/arm/mm/fault.c
> > @@ -393,6 +393,9 @@ do_translation_fault(unsigned long addr, unsigned int fsr,
> >  	if (addr < TASK_SIZE)
> >  		return do_page_fault(addr, fsr, regs);
> >  
> > +	if (user_mode(regs) && addr >= TASK_SIZE)
> > +		goto bad_area;
> > +
> 
> technically, addr >= TASK_SIZE was guaranteed by the previous test
> on addr. The user_mode(regs) may well be a good idea, although I'm
> not sure if we get entered here if the kernel is attempting to access
> user-mode memory by forcing unpriveldged accesses.
> 
> probably best to get Russell's opinion.

	if (user_mode(regs))
		goto bad_area;

should be sufficient, since userspace should not be accessing anything
above TASK_SIZE, except for the exception page, which will always be
mapped.

kernel virtual memory access (from app) does not generate segfault

[Jamie Lokier]

Russell King - ARM Linux wrote:
> On Tue, Apr 20, 2010 at 06:09:44PM +0100, Ben Dooks wrote:
> > On Tue, Apr 20, 2010 at 10:20:47PM +0800, anfei wrote:
> > > On Tue, Apr 20, 2010 at 11:27:40AM +0100, Dave P. Martin wrote:
> > > > > From: linux-arm-kernel-bounces at lists.infradead.org 
> > > > > [mailto:linux-arm-kernel-bounces at lists.infradead.org] On 
> > > > > Behalf Of Ben Dooks
> > > > > Your first example writes to an area, your second is 
> > > > > execution. IIRC, this version of the ARM architecture equates 
> > > > > read and execute permission and so you may actually have 
> > > > > permission to read this area and thus execute code in it.
> 
> User programs do not have permission to read kernel addresses.  Trying to
> do so _should_ generate a permission fault.
>
> > probably best to get Russell's opinion.
> 
> 	if (user_mode(regs))
> 		goto bad_area;
> 
> should be sufficient, since userspace should not be accessing anything
> above TASK_SIZE, except for the exception page, which will always be
> mapped.

Those two lines look good to me, or alternatively change

        if (addr < TASK_SIZE)
to 
        if (addr < TASK_SIZE || user_mode(regs))

which lead to the same SIGSEGV by a more complicated route.  That will
continue to work if user-accessible pages are ever mapped using the
vmalloc lazy method.  Currently not, and I'm sure if that's ever done
it will be noticed quickly :-)

But a possible NAK: What happens when the kernel does get/put_user()
on an address > TASK_SIZE with kernel-only mapping?  user_mode()
returns 0, so the LDRT will loop in the kernel, won't it?

Reviewed-by: Jamie Lokier <jamie@shareable.org>

-- Jamie

kernel virtual memory access (from app) does not generate segfault

[Russell King - ARM Linux]

On Tue, Apr 20, 2010 at 11:31:06PM +0100, Jamie Lokier wrote:
> Russell King - ARM Linux wrote:
> > User programs do not have permission to read kernel addresses.  Trying to
> > do so _should_ generate a permission fault.
> >
> > > probably best to get Russell's opinion.
> > 
> > 	if (user_mode(regs))
> > 		goto bad_area;
> > 
> > should be sufficient, since userspace should not be accessing anything
> > above TASK_SIZE, except for the exception page, which will always be
> > mapped.
> 
> Those two lines look good to me, or alternatively change
> 
>         if (addr < TASK_SIZE)
> to 
>         if (addr < TASK_SIZE || user_mode(regs))
> 
> which lead to the same SIGSEGV by a more complicated route.  That will
> continue to work if user-accessible pages are ever mapped using the
> vmalloc lazy method.

That'd be very disgusting if it ever happened.

> But a possible NAK: What happens when the kernel does get/put_user()
> on an address > TASK_SIZE with kernel-only mapping?  user_mode()
> returns 0, so the LDRT will loop in the kernel, won't it?

No - the first data fault will cause the pgd entry to be copied, and then
the subsequent data fault will be a permission fault.

The difference between instruction faults and data faults is that we
always interpret instruction faults on pre-ARMv6 CPUs as a 'translation
fault' rather than a permission fault since they can't tell us what the
problem was.

kernel virtual memory access (from app) does not generate segfault

[Jamie Lokier]

Russell King - ARM Linux wrote:
> On Tue, Apr 20, 2010 at 11:31:06PM +0100, Jamie Lokier wrote:
> > But a possible NAK: What happens when the kernel does get/put_user()
> > on an address > TASK_SIZE with kernel-only mapping?  user_mode()
> > returns 0, so the LDRT will loop in the kernel, won't it?
> 
> No - the first data fault will cause the pgd entry to be copied, and then
> the subsequent data fault will be a permission fault.
> 
> The difference between instruction faults and data faults is that we
> always interpret instruction faults on pre-ARMv6 CPUs as a 'translation
> fault' rather than a permission fault since they can't tell us what the
> problem was.

Subtle, but nice.

So are the ifar_info and ifsr_info tables completely redundant
pre-ARMv6, or is it just ifsr_info?

-- Jamie

kernel virtual memory access (from app) does not generatesegfault

[Dave P. Martin]

 

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk] 
> Sent: 20 April 2010 23:41
> To: Jamie Lokier
> Cc: Ben Dooks; anfei; Dave P Martin; 
> linux-arm-kernel at lists.infradead.org
> Subject: Re: kernel virtual memory access (from app) does not 
> generatesegfault

[...]

> The difference between instruction faults and data faults is 
> that we always interpret instruction faults on pre-ARMv6 CPUs 
> as a 'translation fault' rather than a permission fault since 
> they can't tell us what the problem was.

Note that my observations were on an armv7 kernel.  Should we still hit the
same bit of code in this case, or have I misdiagnosed the problem?

Cheers
---Dave

kernel virtual memory access (from app) does not generatesegfault

[anfei]

On Wed, Apr 21, 2010 at 12:17:41PM +0100, Dave P. Martin wrote:
>  
> 
> > -----Original Message-----
> > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk] 
> > Sent: 20 April 2010 23:41
> > To: Jamie Lokier
> > Cc: Ben Dooks; anfei; Dave P Martin; 
> > linux-arm-kernel at lists.infradead.org
> > Subject: Re: kernel virtual memory access (from app) does not 
> > generatesegfault
> 
> [...]
> 
> > The difference between instruction faults and data faults is 
> > that we always interpret instruction faults on pre-ARMv6 CPUs 
> > as a 'translation fault' rather than a permission fault since 
> > they can't tell us what the problem was.
> 
> Note that my observations were on an armv7 kernel.  Should we still hit the
> same bit of code in this case, or have I misdiagnosed the problem?
> 
You said your kernel is .28, so it seems too old and this commit may fix
it: 
commit d25ef8b86e6a58f5476bf6e4a8da730b335f68fa
	ARM: 5728/1: Proper prefetch abort handling on ARMv6 and ARMv7

Cheers,
Anfei.

> Cheers
> ---Dave
> 
> 
> 

kernel virtual memory access (from app) does not generatesegfault

[Dave P. Martin]

 

> -----Original Message-----
> From: anfei [mailto:anfei.zhou at gmail.com] 
> Sent: 21 April 2010 13:43
> To: Dave P Martin
> Cc: 'Russell King - ARM Linux'; Jamie Lokier; Ben Dooks; 
> linux-arm-kernel at lists.infradead.org
> Subject: Re: kernel virtual memory access (from app) does not 
> generatesegfault

[...]

> > > The difference between instruction faults and data faults 
> is that we 
> > > always interpret instruction faults on pre-ARMv6 CPUs as a 
> > > 'translation fault' rather than a permission fault since 
> they can't 
> > > tell us what the problem was.
> > 
> > Note that my observations were on an armv7 kernel.  Should we still 
> > hit the same bit of code in this case, or have I 
> misdiagnosed the problem?
> > 
> You said your kernel is .28, so it seems too old and this 
> commit may fix
> it: 
> commit d25ef8b86e6a58f5476bf6e4a8da730b335f68fa
> 	ARM: 5728/1: Proper prefetch abort handling on ARMv6 and ARMv7
> 

Just to clarify, this problem was not specific to 2.6.28.  I also see the
same issue on the 2.6.31 Ubuntu lucid kernel.

So I guess I did misdiagnose the problem, though the affected code did look
worth tweaking anyway--- the suggested fixes looked sensible to me.

I see this patch didn't hit mainline before 2.6.32; I'll suggest to the
Ubuntu folks that they merge this, but I guess it's not critical for them
--- I don't think they've seen any real-life instances of this problem yet.

Cheers
---Dave

kernel virtual memory access (from app) does not generatesegfault

[Jamie Lokier]

Dave P. Martin wrote:
>  
> 
> > -----Original Message-----
> > From: anfei [mailto:anfei.zhou at gmail.com] 
> > Sent: 21 April 2010 13:43
> > To: Dave P Martin
> > Cc: 'Russell King - ARM Linux'; Jamie Lokier; Ben Dooks; 
> > linux-arm-kernel at lists.infradead.org
> > Subject: Re: kernel virtual memory access (from app) does not 
> > generatesegfault
> 
> [...]
> 
> > > > The difference between instruction faults and data faults 
> > is that we 
> > > > always interpret instruction faults on pre-ARMv6 CPUs as a 
> > > > 'translation fault' rather than a permission fault since 
> > they can't 
> > > > tell us what the problem was.
> > > 
> > > Note that my observations were on an armv7 kernel.  Should we still 
> > > hit the same bit of code in this case, or have I 
> > misdiagnosed the problem?
> > > 
> > You said your kernel is .28, so it seems too old and this 
> > commit may fix
> > it: 
> > commit d25ef8b86e6a58f5476bf6e4a8da730b335f68fa
> > 	ARM: 5728/1: Proper prefetch abort handling on ARMv6 and ARMv7
> > 
> 
> Just to clarify, this problem was not specific to 2.6.28.  I also see the
> same issue on the 2.6.31 Ubuntu lucid kernel.
> 
> So I guess I did misdiagnose the problem, though the affected code did look
> worth tweaking anyway--- the suggested fixes looked sensible to me.
> 
> I see this patch didn't hit mainline before 2.6.32; I'll suggest to the
> Ubuntu folks that they merge this, but I guess it's not critical for them
> --- I don't think they've seen any real-life instances of this problem yet.

The two-liner proposed earlier should fix all ARMs doing userspace
execution > TASK_SIZE - the problem which started this thread.  But
not kernel space accidentally executing an NX page > TASK_SIZE due to
some bug, which can only occur on ARMv6/v7 due to NX.

The above patch addresses ARMv6/v7 with NX mappings - and probably
only those > TASK_SIZE; NX mappings < TASK_SIZE should have been
caught by the PROT_EXEC check already in fault.c.

If I'm right, the NX one is more serious if you can trip a kernel bug
into doing this, because it'll result in an unkillable process, stuck
in kernel mode and spinning.  But only if you trip a kernel bug.

So both patches look useful.

-- Jamie

kernel virtual memory access (from app) does not generatesegfault

[Russell King - ARM Linux]

On Wed, Apr 21, 2010 at 08:16:00PM +0100, Jamie Lokier wrote:
> The two-liner proposed earlier should fix all ARMs doing userspace
> execution > TASK_SIZE - the problem which started this thread.  But
> not kernel space accidentally executing an NX page > TASK_SIZE due to
> some bug, which can only occur on ARMv6/v7 due to NX.

Sorry James, that's wrong.  ARMv6 and ARMv7 use the IFSR, which gives
us the error code - and that distinguishes between a translation fault
and a permission fault.  An attempt to execute a NX page generates a
permission fault, and therefore we end up calling do_page_fault() rather
than indirecting via do_translation_fault().

kernel virtual memory access (from app) does not generatesegfault

[Jamie Lokier]

Russell King - ARM Linux wrote:
> On Wed, Apr 21, 2010 at 08:16:00PM +0100, Jamie Lokier wrote:
> > The two-liner proposed earlier should fix all ARMs doing userspace
> > execution > TASK_SIZE - the problem which started this thread.  But
> > not kernel space accidentally executing an NX page > TASK_SIZE due to
> > some bug, which can only occur on ARMv6/v7 due to NX.
> 
> Sorry James, that's wrong.

It's Jamie, btw.  Always has been.

> ARMv6 and ARMv7 use the IFSR, which gives us the error code - and
> that distinguishes between a translation fault and a permission
> fault.  An attempt to execute a NX page generates a permission
> fault, and therefore we end up calling do_page_fault() rather than
> indirecting via do_translation_fault().

That's a fine explanation, but I'd already grokked it, thanks to your
earlier hint.  So what's wrong about what I said above?  Rephrased as:

Kernel executes NX page > TASK_SIZE:

    Without patch, loops calling do_translation_fault() which
    just returns because the pte is already mapped and valid.
    With patch, goes to do_page_fault().

    -> Fixed by the IFSR patch.

User executes NX page > TASK_SIZE

    -> Fixed by the two-liner or IFSR patch, it doesn't matter.
       Either one directs these to do_page_fault().

Kernel executes NX page < TASK_SIZE:

    -> Already caught by PROT_EXEC + FSR_LNF_PX check in
       do_translation_fault -> do_page-fault -> access_error.

User executes NX page < TASK_SIZE:

    -> Already caught by PROT_EXEC + FSR_LNF_PX check in
       do_translation_fault -> do_page-fault -> access_error.

-- Jamie

kernel virtual memory access (from app) does not generatesegfault

[Russell King - ARM Linux]

On Wed, Apr 21, 2010 at 08:43:17PM +0800, anfei wrote:
> On Wed, Apr 21, 2010 at 12:17:41PM +0100, Dave P. Martin wrote:
> > Note that my observations were on an armv7 kernel.  Should we still hit the
> > same bit of code in this case, or have I misdiagnosed the problem?
> > 
> You said your kernel is .28, so it seems too old and this commit may fix
> it: 
> commit d25ef8b86e6a58f5476bf6e4a8da730b335f68fa
> 	ARM: 5728/1: Proper prefetch abort handling on ARMv6 and ARMv7

Indeed, yes.  However, I think the fix is still value for older CPUs.

kernel virtual memory access (from app) does not generatesegfault

[Russell King - ARM Linux]

On Wed, Apr 21, 2010 at 12:17:41PM +0100, Dave P. Martin wrote:
>  
> 
> > -----Original Message-----
> > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk] 
> > Sent: 20 April 2010 23:41
> > To: Jamie Lokier
> > Cc: Ben Dooks; anfei; Dave P Martin; 
> > linux-arm-kernel at lists.infradead.org
> > Subject: Re: kernel virtual memory access (from app) does not 
> > generatesegfault
> 
> [...]
> 
> > The difference between instruction faults and data faults is 
> > that we always interpret instruction faults on pre-ARMv6 CPUs 
> > as a 'translation fault' rather than a permission fault since 
> > they can't tell us what the problem was.
> 
> Note that my observations were on an armv7 kernel.  Should we still hit the
> same bit of code in this case, or have I misdiagnosed the problem?

If it was ARMv7, we should be reading the IFSR, which should be telling
us that there's a permission fault trying to read instructions from
0xc0000000.

If changing do_translation_fault() on a recent kernel fixes your problem,
something's going wrong.  Any chance you could add some debugging to
do_PrefetchAbort() so that when you see your test program running
(eg, if (strcmp(current->comm, "progname") == 0) { ... }) you could
dump out the values of ifsr and addr please?

kernel virtual memory access (from app) does not generatesegfault

[Nicolas Pitre]

On Wed, 21 Apr 2010, Russell King - ARM Linux wrote:

> On Wed, Apr 21, 2010 at 12:17:41PM +0100, Dave P. Martin wrote:
> >  
> > 
> > > -----Original Message-----
> > > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk] 
> > > Sent: 20 April 2010 23:41
> > > To: Jamie Lokier
> > > Cc: Ben Dooks; anfei; Dave P Martin; 
> > > linux-arm-kernel at lists.infradead.org
> > > Subject: Re: kernel virtual memory access (from app) does not 
> > > generatesegfault
> > 
> > [...]
> > 
> > > The difference between instruction faults and data faults is 
> > > that we always interpret instruction faults on pre-ARMv6 CPUs 
> > > as a 'translation fault' rather than a permission fault since 
> > > they can't tell us what the problem was.
> > 
> > Note that my observations were on an armv7 kernel.  Should we still hit the
> > same bit of code in this case, or have I misdiagnosed the problem?
> 
> If it was ARMv7, we should be reading the IFSR, which should be telling
> us that there's a permission fault trying to read instructions from
> 0xc0000000.
> 
> If changing do_translation_fault() on a recent kernel fixes your problem,
> something's going wrong.  Any chance you could add some debugging to
> do_PrefetchAbort() so that when you see your test program running
> (eg, if (strcmp(current->comm, "progname") == 0) { ... }) you could
> dump out the values of ifsr and addr please?

If I remember right, the original bug report mentioned ARM926.


Nicolas

kernel virtual memory access (from app) does not generatesegfault

[Russell King - ARM Linux]

On Wed, Apr 21, 2010 at 05:24:51PM -0400, Nicolas Pitre wrote:
> On Wed, 21 Apr 2010, Russell King - ARM Linux wrote:
> 
> > On Wed, Apr 21, 2010 at 12:17:41PM +0100, Dave P. Martin wrote:
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk] 
> > > > Sent: 20 April 2010 23:41
> > > > To: Jamie Lokier
> > > > Cc: Ben Dooks; anfei; Dave P Martin; 
> > > > linux-arm-kernel at lists.infradead.org
> > > > Subject: Re: kernel virtual memory access (from app) does not 
> > > > generatesegfault
> > > 
> > > [...]
> > > 
> > > > The difference between instruction faults and data faults is 
> > > > that we always interpret instruction faults on pre-ARMv6 CPUs 
> > > > as a 'translation fault' rather than a permission fault since 
> > > > they can't tell us what the problem was.
> > > 
> > > Note that my observations were on an armv7 kernel.  Should we still hit the
> > > same bit of code in this case, or have I misdiagnosed the problem?
> > 
> > If it was ARMv7, we should be reading the IFSR, which should be telling
> > us that there's a permission fault trying to read instructions from
> > 0xc0000000.
> > 
> > If changing do_translation_fault() on a recent kernel fixes your problem,
> > something's going wrong.  Any chance you could add some debugging to
> > do_PrefetchAbort() so that when you see your test program running
> > (eg, if (strcmp(current->comm, "progname") == 0) { ... }) you could
> > dump out the values of ifsr and addr please?
> 
> If I remember right, the original bug report mentioned ARM926.

So here we go again with confusion raining.

Someone please tell me _definitively_ _what_ is being seen on _what_ CPU,
and separate the two issues into two different threads.  I'm going to
ignore any further comments on this issue until that's done.  Life is
too short to try to work this out on my own.

kernel virtual memory access (from app) does not generatesegfault

[Russell King - ARM Linux]

On Wed, Apr 21, 2010 at 10:44:47PM +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 21, 2010 at 05:24:51PM -0400, Nicolas Pitre wrote:
> > On Wed, 21 Apr 2010, Russell King - ARM Linux wrote:
> > 
> > > On Wed, Apr 21, 2010 at 12:17:41PM +0100, Dave P. Martin wrote:
> > > >  
> > > > 
> > > > > -----Original Message-----
> > > > > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk] 
> > > > > Sent: 20 April 2010 23:41
> > > > > To: Jamie Lokier
> > > > > Cc: Ben Dooks; anfei; Dave P Martin; 
> > > > > linux-arm-kernel at lists.infradead.org
> > > > > Subject: Re: kernel virtual memory access (from app) does not 
> > > > > generatesegfault
> > > > 
> > > > [...]
> > > > 
> > > > > The difference between instruction faults and data faults is 
> > > > > that we always interpret instruction faults on pre-ARMv6 CPUs 
> > > > > as a 'translation fault' rather than a permission fault since 
> > > > > they can't tell us what the problem was.
> > > > 
> > > > Note that my observations were on an armv7 kernel.  Should we still hit the
> > > > same bit of code in this case, or have I misdiagnosed the problem?
> > > 
> > > If it was ARMv7, we should be reading the IFSR, which should be telling
> > > us that there's a permission fault trying to read instructions from
> > > 0xc0000000.
> > > 
> > > If changing do_translation_fault() on a recent kernel fixes your problem,
> > > something's going wrong.  Any chance you could add some debugging to
> > > do_PrefetchAbort() so that when you see your test program running
> > > (eg, if (strcmp(current->comm, "progname") == 0) { ... }) you could
> > > dump out the values of ifsr and addr please?
> > 
> > If I remember right, the original bug report mentioned ARM926.
> 
> So here we go again with confusion raining.
> 
> Someone please tell me _definitively_ _what_ is being seen on _what_ CPU,
> and separate the two issues into two different threads.  I'm going to
> ignore any further comments on this issue until that's done.  Life is
> too short to try to work this out on my own.

Actually, no, you're creating the confusion; this sub-thread is about
the behaviour on ARMv7, as a completely separate subject from ARM926.

kernel virtual memory access (from app) does not generatesegfault

[Nicolas Pitre]

On Wed, 21 Apr 2010, Russell King - ARM Linux wrote:

> On Wed, Apr 21, 2010 at 10:44:47PM +0100, Russell King - ARM Linux wrote:
> > On Wed, Apr 21, 2010 at 05:24:51PM -0400, Nicolas Pitre wrote:
> > > On Wed, 21 Apr 2010, Russell King - ARM Linux wrote:
> > > 
> > > > On Wed, Apr 21, 2010 at 12:17:41PM +0100, Dave P. Martin wrote:
> > > > >  
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk] 
> > > > > > Sent: 20 April 2010 23:41
> > > > > > To: Jamie Lokier
> > > > > > Cc: Ben Dooks; anfei; Dave P Martin; 
> > > > > > linux-arm-kernel at lists.infradead.org
> > > > > > Subject: Re: kernel virtual memory access (from app) does not 
> > > > > > generatesegfault
> > > > > 
> > > > > [...]
> > > > > 
> > > > > > The difference between instruction faults and data faults is 
> > > > > > that we always interpret instruction faults on pre-ARMv6 CPUs 
> > > > > > as a 'translation fault' rather than a permission fault since 
> > > > > > they can't tell us what the problem was.
> > > > > 
> > > > > Note that my observations were on an armv7 kernel.  Should we still hit the
> > > > > same bit of code in this case, or have I misdiagnosed the problem?
> > > > 
> > > > If it was ARMv7, we should be reading the IFSR, which should be telling
> > > > us that there's a permission fault trying to read instructions from
> > > > 0xc0000000.
> > > > 
> > > > If changing do_translation_fault() on a recent kernel fixes your problem,
> > > > something's going wrong.  Any chance you could add some debugging to
> > > > do_PrefetchAbort() so that when you see your test program running
> > > > (eg, if (strcmp(current->comm, "progname") == 0) { ... }) you could
> > > > dump out the values of ifsr and addr please?
> > > 
> > > If I remember right, the original bug report mentioned ARM926.
> > 
> > So here we go again with confusion raining.
> > 
> > Someone please tell me _definitively_ _what_ is being seen on _what_ CPU,
> > and separate the two issues into two different threads.  I'm going to
> > ignore any further comments on this issue until that's done.  Life is
> > too short to try to work this out on my own.
> 
> Actually, no, you're creating the confusion; this sub-thread is about
> the behaviour on ARMv7, as a completely separate subject from ARM926.

It is well possible that I missed the subject transition.

The only person who provided a test program is Sasha Sirotkin who said:

On Tue, 20 Apr 2010, Sasha Sirotkin wrote:

> P.S. My kernel is 2.6.32.7 and the CPU is ARM926EJ-S rev 5 (v5l)

Message-id: <4BCD7076.9030802@browserseal.com>

Only later did Dave P. Martin mention having made similar observations 
on an ARMv7.


Nicolas

kernel virtual memory access (from app) does not generatesegfault

[Dave P. Martin]

Hi there, 

> -----Original Message-----
> From: Nicolas Pitre [mailto:nico at fluxnic.net] 
> Sent: 21 April 2010 23:59
> To: Russell King - ARM Linux
> Cc: linux-arm-kernel at lists.infradead.org; anfei; Jamie 
> Lokier; Dave P Martin; Ben Dooks
> Subject: Re: kernel virtual memory access (from app) does not 
> generatesegfault
> 
> On Wed, 21 Apr 2010, Russell King - ARM Linux wrote:
> 
> > On Wed, Apr 21, 2010 at 10:44:47PM +0100, Russell King - 
> ARM Linux wrote:
> > > On Wed, Apr 21, 2010 at 05:24:51PM -0400, Nicolas Pitre wrote:
> > > > On Wed, 21 Apr 2010, Russell King - ARM Linux wrote:
> > > > 
> > > > > On Wed, Apr 21, 2010 at 12:17:41PM +0100, Dave P. 
> Martin wrote:
> > > > > >  
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Russell King - ARM Linux 
> > > > > > > [mailto:linux at arm.linux.org.uk]
> > > > > > > Sent: 20 April 2010 23:41
> > > > > > > To: Jamie Lokier
> > > > > > > Cc: Ben Dooks; anfei; Dave P Martin; 
> > > > > > > linux-arm-kernel at lists.infradead.org
> > > > > > > Subject: Re: kernel virtual memory access (from app) does 
> > > > > > > not generatesegfault
> > > > > > 
> > > > > > [...]
> > > > > > 
> > > > > > > The difference between instruction faults and 
> data faults is 
> > > > > > > that we always interpret instruction faults on pre-ARMv6 
> > > > > > > CPUs as a 'translation fault' rather than a 
> permission fault 
> > > > > > > since they can't tell us what the problem was.
> > > > > > 
> > > > > > Note that my observations were on an armv7 kernel.  
> Should we 
> > > > > > still hit the same bit of code in this case, or 
> have I misdiagnosed the problem?
> > > > > 
> > > > > If it was ARMv7, we should be reading the IFSR, which 
> should be 
> > > > > telling us that there's a permission fault trying to read 
> > > > > instructions from 0xc0000000.
> > > > > 
> > > > > If changing do_translation_fault() on a recent kernel 
> fixes your 
> > > > > problem, something's going wrong.  Any chance you 
> could add some 
> > > > > debugging to
> > > > > do_PrefetchAbort() so that when you see your test program 
> > > > > running (eg, if (strcmp(current->comm, "progname") == 
> 0) { ... 
> > > > > }) you could dump out the values of ifsr and addr please?
> > > > 
> > > > If I remember right, the original bug report mentioned ARM926.
> > > 
> > > So here we go again with confusion raining.
> > > 
> > > Someone please tell me _definitively_ _what_ is being 
> seen on _what_ 
> > > CPU, and separate the two issues into two different threads.  I'm 
> > > going to ignore any further comments on this issue until that's 
> > > done.  Life is too short to try to work this out on my own.
> > 
> > Actually, no, you're creating the confusion; this 
> sub-thread is about 
> > the behaviour on ARMv7, as a completely separate subject 
> from ARM926.
> 
> It is well possible that I missed the subject transition.
> 
> The only person who provided a test program is Sasha Sirotkin 
> who said:
> 
> On Tue, 20 Apr 2010, Sasha Sirotkin wrote:
> 
> > P.S. My kernel is 2.6.32.7 and the CPU is ARM926EJ-S rev 5 (v5l)
> 
> Message-id: <4BCD7076.9030802@browserseal.com>
> 
> Only later did Dave P. Martin mention having made similar 
> observations on an ARMv7.

To clarify:

	* I haven't tested this on 926 myself
	* On armv7, I have observed the problem only on *old* kernels
(<2.6.32; which lack any of the patches under discussion)
	* Using 2.6.34-rc1 (from rmk's versatile branch) on armv7, I get the
expected SEGV when userspace tries to execute >= TASK_SIZE

so...
	* Sasha's problem is caused by a problem in the current kernel on
926.
	* My problem relates to v7 and has already been fixed (but isn't
fixed in the Ubuntu kernels yet)

The test case was

int main(void)
{
	((void (*)(void))0xc0000000)();
	return 0;
}

Hope this makes things clearer.

Cheers
---Dave

kernel virtual memory access (from app) does not generatesegfault

[anfei]

On Thu, Apr 22, 2010 at 11:56:09AM +0100, Dave P. Martin wrote:
> Hi there, 
> 
> > -----Original Message-----
> > From: Nicolas Pitre [mailto:nico at fluxnic.net] 
> > Sent: 21 April 2010 23:59
> > To: Russell King - ARM Linux
> > Cc: linux-arm-kernel at lists.infradead.org; anfei; Jamie 
> > Lokier; Dave P Martin; Ben Dooks
> > Subject: Re: kernel virtual memory access (from app) does not 
> > generatesegfault
> > 
> > On Wed, 21 Apr 2010, Russell King - ARM Linux wrote:
> > 
> > > On Wed, Apr 21, 2010 at 10:44:47PM +0100, Russell King - 
> > ARM Linux wrote:
> > > > On Wed, Apr 21, 2010 at 05:24:51PM -0400, Nicolas Pitre wrote:
> > > > > On Wed, 21 Apr 2010, Russell King - ARM Linux wrote:
> > > > > 
> > > > > > On Wed, Apr 21, 2010 at 12:17:41PM +0100, Dave P. 
> > Martin wrote:
> > > > > > >  
> > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Russell King - ARM Linux 
> > > > > > > > [mailto:linux at arm.linux.org.uk]
> > > > > > > > Sent: 20 April 2010 23:41
> > > > > > > > To: Jamie Lokier
> > > > > > > > Cc: Ben Dooks; anfei; Dave P Martin; 
> > > > > > > > linux-arm-kernel at lists.infradead.org
> > > > > > > > Subject: Re: kernel virtual memory access (from app) does 
> > > > > > > > not generatesegfault
> > > > > > > 
> > > > > > > [...]
> > > > > > > 
> > > > > > > > The difference between instruction faults and 
> > data faults is 
> > > > > > > > that we always interpret instruction faults on pre-ARMv6 
> > > > > > > > CPUs as a 'translation fault' rather than a 
> > permission fault 
> > > > > > > > since they can't tell us what the problem was.
> > > > > > > 
> > > > > > > Note that my observations were on an armv7 kernel.  
> > Should we 
> > > > > > > still hit the same bit of code in this case, or 
> > have I misdiagnosed the problem?
> > > > > > 
> > > > > > If it was ARMv7, we should be reading the IFSR, which 
> > should be 
> > > > > > telling us that there's a permission fault trying to read 
> > > > > > instructions from 0xc0000000.
> > > > > > 
> > > > > > If changing do_translation_fault() on a recent kernel 
> > fixes your 
> > > > > > problem, something's going wrong.  Any chance you 
> > could add some 
> > > > > > debugging to
> > > > > > do_PrefetchAbort() so that when you see your test program 
> > > > > > running (eg, if (strcmp(current->comm, "progname") == 
> > 0) { ... 
> > > > > > }) you could dump out the values of ifsr and addr please?
> > > > > 
> > > > > If I remember right, the original bug report mentioned ARM926.
> > > > 
> > > > So here we go again with confusion raining.
> > > > 
> > > > Someone please tell me _definitively_ _what_ is being 
> > seen on _what_ 
> > > > CPU, and separate the two issues into two different threads.  I'm 
> > > > going to ignore any further comments on this issue until that's 
> > > > done.  Life is too short to try to work this out on my own.
> > > 
> > > Actually, no, you're creating the confusion; this 
> > sub-thread is about 
> > > the behaviour on ARMv7, as a completely separate subject 
> > from ARM926.
> > 
> > It is well possible that I missed the subject transition.
> > 
> > The only person who provided a test program is Sasha Sirotkin 
> > who said:
> > 
> > On Tue, 20 Apr 2010, Sasha Sirotkin wrote:
> > 
> > > P.S. My kernel is 2.6.32.7 and the CPU is ARM926EJ-S rev 5 (v5l)
> > 
> > Message-id: <4BCD7076.9030802@browserseal.com>
> > 
> > Only later did Dave P. Martin mention having made similar 
> > observations on an ARMv7.
> 
> To clarify:
> 
> 	* I haven't tested this on 926 myself
> 	* On armv7, I have observed the problem only on *old* kernels
> (<2.6.32; which lack any of the patches under discussion)
> 	* Using 2.6.34-rc1 (from rmk's versatile branch) on armv7, I get the
> expected SEGV when userspace tries to execute >= TASK_SIZE
> 
> so...
> 	* Sasha's problem is caused by a problem in the current kernel on
> 926.
> 	* My problem relates to v7 and has already been fixed (but isn't
> fixed in the Ubuntu kernels yet)
> 
> The test case was
> 
> int main(void)
> {
> 	((void (*)(void))0xc0000000)();
> 	return 0;
> }
> 
I did a test on arm926 using QEMU with the latest kernel (just pull from
git.kernel.org).  Without checking user_mode, this test case will
continue to trigger do_translation_fault with address 0xc0000000, so I
think that two-liner patch is necessary.  With it, the case will get
SIGSEGV, and the system seems running well.

Regards,
Anfei.

> Hope this makes things clearer.
> 
> Cheers
> ---Dave
> 
> 

kernel virtual memory access (from app) does not generatesegfault

[Dave P. Martin]

 

> -----Original Message-----
> From: anfei [mailto:anfei.zhou at gmail.com] 
> Sent: 22 April 2010 13:29
> To: Dave P Martin
> Cc: 'Nicolas Pitre'; Russell King - ARM Linux; 
> linux-arm-kernel at lists.infradead.org; Jamie Lokier; Ben Dooks
> Subject: Re: kernel virtual memory access (from app) does not 
> generatesegfault
> 
> On Thu, Apr 22, 2010 at 11:56:09AM +0100, Dave P. Martin wrote:
> > Hi there,
> > 
> > > -----Original Message-----
> > > From: Nicolas Pitre [mailto:nico at fluxnic.net]
> > > Sent: 21 April 2010 23:59
> > > To: Russell King - ARM Linux
> > > Cc: linux-arm-kernel at lists.infradead.org; anfei; Jamie 
> Lokier; Dave 
> > > P Martin; Ben Dooks
> > > Subject: Re: kernel virtual memory access (from app) does not 
> > > generatesegfault
> > > 
> > > On Wed, 21 Apr 2010, Russell King - ARM Linux wrote:
> > > 
> > > > On Wed, Apr 21, 2010 at 10:44:47PM +0100, Russell King -
> > > ARM Linux wrote:
> > > > > On Wed, Apr 21, 2010 at 05:24:51PM -0400, Nicolas Pitre wrote:
> > > > > > On Wed, 21 Apr 2010, Russell King - ARM Linux wrote:
> > > > > > 
> > > > > > > On Wed, Apr 21, 2010 at 12:17:41PM +0100, Dave P. 
> > > Martin wrote:
> > > > > > > >  
> > > > > > > > 
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Russell King - ARM Linux 
> > > > > > > > > [mailto:linux at arm.linux.org.uk]
> > > > > > > > > Sent: 20 April 2010 23:41
> > > > > > > > > To: Jamie Lokier
> > > > > > > > > Cc: Ben Dooks; anfei; Dave P Martin; 
> > > > > > > > > linux-arm-kernel at lists.infradead.org
> > > > > > > > > Subject: Re: kernel virtual memory access (from app) 
> > > > > > > > > does not generatesegfault
> > > > > > > > 
> > > > > > > > [...]
> > > > > > > > 
> > > > > > > > > The difference between instruction faults and
> > > data faults is
> > > > > > > > > that we always interpret instruction faults 
> on pre-ARMv6 
> > > > > > > > > CPUs as a 'translation fault' rather than a
> > > permission fault
> > > > > > > > > since they can't tell us what the problem was.
> > > > > > > > 
> > > > > > > > Note that my observations were on an armv7 kernel.  
> > > Should we
> > > > > > > > still hit the same bit of code in this case, or
> > > have I misdiagnosed the problem?
> > > > > > > 
> > > > > > > If it was ARMv7, we should be reading the IFSR, which
> > > should be
> > > > > > > telling us that there's a permission fault trying to read 
> > > > > > > instructions from 0xc0000000.
> > > > > > > 
> > > > > > > If changing do_translation_fault() on a recent kernel
> > > fixes your
> > > > > > > problem, something's going wrong.  Any chance you
> > > could add some
> > > > > > > debugging to
> > > > > > > do_PrefetchAbort() so that when you see your test program 
> > > > > > > running (eg, if (strcmp(current->comm, "progname") ==
> > > 0) { ... 
> > > > > > > }) you could dump out the values of ifsr and addr please?
> > > > > > 
> > > > > > If I remember right, the original bug report 
> mentioned ARM926.
> > > > > 
> > > > > So here we go again with confusion raining.
> > > > > 
> > > > > Someone please tell me _definitively_ _what_ is being
> > > seen on _what_
> > > > > CPU, and separate the two issues into two different threads.  
> > > > > I'm going to ignore any further comments on this issue until 
> > > > > that's done.  Life is too short to try to work this 
> out on my own.
> > > > 
> > > > Actually, no, you're creating the confusion; this
> > > sub-thread is about
> > > > the behaviour on ARMv7, as a completely separate subject
> > > from ARM926.
> > > 
> > > It is well possible that I missed the subject transition.
> > > 
> > > The only person who provided a test program is Sasha Sirotkin who 
> > > said:
> > > 
> > > On Tue, 20 Apr 2010, Sasha Sirotkin wrote:
> > > 
> > > > P.S. My kernel is 2.6.32.7 and the CPU is ARM926EJ-S rev 5 (v5l)
> > > 
> > > Message-id: <4BCD7076.9030802@browserseal.com>
> > > 
> > > Only later did Dave P. Martin mention having made similar 
> > > observations on an ARMv7.
> > 
> > To clarify:
> > 
> > 	* I haven't tested this on 926 myself
> > 	* On armv7, I have observed the problem only on *old* kernels 
> > (<2.6.32; which lack any of the patches under discussion)
> > 	* Using 2.6.34-rc1 (from rmk's versatile branch) on 
> armv7, I get the 
> > expected SEGV when userspace tries to execute >= TASK_SIZE
> > 
> > so...
> > 	* Sasha's problem is caused by a problem in the current 
> kernel on 
> > 926.
> > 	* My problem relates to v7 and has already been fixed 
> (but isn't 
> > fixed in the Ubuntu kernels yet)
> > 
> > The test case was
> > 
> > int main(void)
> > {
> > 	((void (*)(void))0xc0000000)();
> > 	return 0;
> > }
> > 
> I did a test on arm926 using QEMU with the latest kernel 
> (just pull from git.kernel.org).  Without checking user_mode, 
> this test case will continue to trigger do_translation_fault 
> with address 0xc0000000, so I think that two-liner patch is 
> necessary.  With it, the case will get SIGSEGV, and the 
> system seems running well.
> 
> Regards,
> Anfei.

That matches my understanding--- it sounds like the two-liner is relevant
for all pre-v6 platforms (including ARM926), so it probably makes sense to
merge it.

---Dave

kernel virtual memory access (from app) does not generatesegfault

[Jamie Lokier]

Dave P. Martin wrote:
> From: anfei [mailto:anfei.zhou at gmail.com] 
> > On Thu, Apr 22, 2010 at 11:56:09AM +0100, Dave P. Martin wrote:
> > >   * I haven't tested this on 926 myself
> > >   * On armv7, I have observed the problem only on *old* kernels 
> > > (<2.6.32; which lack any of the patches under discussion)
> > >   * Using 2.6.34-rc1 (from rmk's versatile branch) on 
> > armv7, I get the 
> > > expected SEGV when userspace tries to execute >= TASK_SIZE
> > > 
> > > so...
> > >   * Sasha's problem is caused by a problem in the current kernel
> > >   on 926.
> > >   * My problem relates to v7 and has already been fixed (but isn't 
> > > fixed in the Ubuntu kernels yet)
> > > 
> > > The test case was
> > > 
> > > int main(void)
> > > {
> > >   ((void (*)(void))0xc0000000)();
> > >   return 0;
> > > }
> > > 
> > I did a test on arm926 using QEMU with the latest kernel 
> > (just pull from git.kernel.org).  Without checking user_mode, 
> > this test case will continue to trigger do_translation_fault 
> > with address 0xc0000000, so I think that two-liner patch is 
> > necessary.  With it, the case will get SIGSEGV, and the 
> > system seems running well.
> 
> That matches my understanding--- it sounds like the two-liner is relevant
> for all pre-v6 platforms (including ARM926), so it probably makes sense to
> merge it.

Good. Both results are consistent with the earlier discussion about
the two patches (one already committed).

There are two different bugs with the same symptom on different
devices.  No wonder Russell's confused by this thread.

The two-liner is the least complicated solution for pre-v6.
Commit the damn thing already ;-)

Reviewed-By: Jamie Lokier <jamie@shareable.org>

-- Jamie

kernel virtual memory access (from app) does not generate segfault

[anfei]

On Tue, Apr 20, 2010 at 08:28:14PM +0100, Russell King - ARM Linux wrote:
> On Tue, Apr 20, 2010 at 06:09:44PM +0100, Ben Dooks wrote:
> > On Tue, Apr 20, 2010 at 10:20:47PM +0800, anfei wrote:
> > > On Tue, Apr 20, 2010 at 11:27:40AM +0100, Dave P. Martin wrote:
> > > >  
> > > > 
> > > > > -----Original Message-----
> > > > > From: linux-arm-kernel-bounces at lists.infradead.org 
> > > > > [mailto:linux-arm-kernel-bounces at lists.infradead.org] On 
> > > > > Behalf Of Ben Dooks
> > > > > Sent: 20 April 2010 10:35
> > > > > To: Sasha Sirotkin
> > > > > Cc: linux-arm-kernel at lists.infradead.org
> > > > > Subject: Re: kernel virtual memory access (from app) does not 
> > > > 
> > > > [..]
> > > > 
> > > > > > For instance, this code generates a segfault allright
> > > > > >
> > > > > > int * aa;
> > > > > > aa = 0xc0000000;
> > > > > > *aa=42;
> > > > > >
> > > > > > However this code does not, instead the process simply 
> > > > > hangs (and can 
> > > > > > be
> > > > > > killed)
> > > > > >
> > > > > > void (*func)(void);
> > > > > > func = 0xc0000000;
> > > > > > func();
> > > > > 
> > > > > Your first example writes to an area, your second is 
> > > > > execution. IIRC, this version of the ARM architecture equates 
> > > > > read and execute permission and so you may actually have 
> > > > > permission to read this area and thus execute code in it.
> 
> User programs do not have permission to read kernel addresses.  Trying to
> do so _should_ generate a permission fault.
> 
> > > > I tried reading that address (albeit on an old 2.6.28 kernel), and I get a
> > > > segfault.
> 
> ... which is correct behaviour.
> 
> > > > Trying to execute in kernel space is the only thing that appears to hang.
> > > > Attaching to the process in gdb, I observed that pc is always 0xc0000000
> > > > when the process is stopped.
> > > > 
> > > > top accounts most of the CPU time as being consumed in the kernel.
> > > > 
> > > > I think what is going on here is that the kernel is catching the expected
> > > > prefetch abort, but the handler fails to send SIGSEGV to the user process
> > > > --- the process is resumed with the same pc and we end up in an endless
> > > > spin.
> 
> Yes, that'd make sense.
> 
> > > diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> > > index 9d40c34..cd4d15c 100644
> > > --- a/arch/arm/mm/fault.c
> > > +++ b/arch/arm/mm/fault.c
> > > @@ -393,6 +393,9 @@ do_translation_fault(unsigned long addr, unsigned int fsr,
> > >  	if (addr < TASK_SIZE)
> > >  		return do_page_fault(addr, fsr, regs);
> > >  
> > > +	if (user_mode(regs) && addr >= TASK_SIZE)
> > > +		goto bad_area;
> > > +
> > 
> > technically, addr >= TASK_SIZE was guaranteed by the previous test
> > on addr. The user_mode(regs) may well be a good idea, although I'm
> > not sure if we get entered here if the kernel is attempting to access
> > user-mode memory by forcing unpriveldged accesses.
> > 
> > probably best to get Russell's opinion.
> 
> 	if (user_mode(regs))
> 		goto bad_area;
> 
> should be sufficient, since userspace should not be accessing anything
> above TASK_SIZE, except for the exception page, which will always be
> mapped.

Patch updated, and with comment log.

===
ARM: Proper prefetch abort handling on pre-ARMv6

Instruction faults on pre-ARMv6 CPUs are interpreted as
a 'translation fault', but do_translation_fault doesn't
handle well if user mode trying to run instruction above
TASK_SIZE, and result in the infinite retry of that
instruction.

Signed-off-by: Anfei Zhou <anfei.zhou@gmail.com>
---
 arch/arm/mm/fault.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 9d40c34..8ad75e9 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -393,6 +393,9 @@ do_translation_fault(unsigned long addr, unsigned int fsr,
 	if (addr < TASK_SIZE)
 		return do_page_fault(addr, fsr, regs);
 
+	if (user_mode(regs))
+		goto bad_area;
+
 	index = pgd_index(addr);
 
 	/*
-- 
1.6.4.rc1

kernel virtual memory access (from app) does not generate segfault

[Jamie Lokier]

anfei wrote:
> ARM: Proper prefetch abort handling on pre-ARMv6
> 
> Instruction faults on pre-ARMv6 CPUs are interpreted as
> a 'translation fault', but do_translation_fault doesn't
> handle well if user mode trying to run instruction above
> TASK_SIZE, and result in the infinite retry of that
> instruction.
> 
> Signed-off-by: Anfei Zhou <anfei.zhou@gmail.com>
> ---
>  arch/arm/mm/fault.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> index 9d40c34..8ad75e9 100644
> --- a/arch/arm/mm/fault.c
> +++ b/arch/arm/mm/fault.c
> @@ -393,6 +393,9 @@ do_translation_fault(unsigned long addr, unsigned int fsr,
>  	if (addr < TASK_SIZE)
>  		return do_page_fault(addr, fsr, regs);
>  
> +	if (user_mode(regs))
> +		goto bad_area;
> +
>  	index = pgd_index(addr);
>  
>  	/*

Looks good to me.

Reviewed-by: Jamie Lokier <jamie@shareable.org>

-- Jamie

kernel virtual memory access (from app) does not generate segfault

[anfei]

Hi Russell,

On Wed, Apr 21, 2010 at 09:11:49PM +0800, anfei wrote:
> On Tue, Apr 20, 2010 at 08:28:14PM +0100, Russell King - ARM Linux wrote:
> > On Tue, Apr 20, 2010 at 06:09:44PM +0100, Ben Dooks wrote:
> > > On Tue, Apr 20, 2010 at 10:20:47PM +0800, anfei wrote:
> > > > On Tue, Apr 20, 2010 at 11:27:40AM +0100, Dave P. Martin wrote:
> > > > >  
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: linux-arm-kernel-bounces at lists.infradead.org 
> > > > > > [mailto:linux-arm-kernel-bounces at lists.infradead.org] On 
> > > > > > Behalf Of Ben Dooks
> > > > > > Sent: 20 April 2010 10:35
> > > > > > To: Sasha Sirotkin
> > > > > > Cc: linux-arm-kernel at lists.infradead.org
> > > > > > Subject: Re: kernel virtual memory access (from app) does not 
> > > > > 
> > > > > [..]
> > > > > 
> > > > > > > For instance, this code generates a segfault allright
> > > > > > >
> > > > > > > int * aa;
> > > > > > > aa = 0xc0000000;
> > > > > > > *aa=42;
> > > > > > >
> > > > > > > However this code does not, instead the process simply 
> > > > > > hangs (and can 
> > > > > > > be
> > > > > > > killed)
> > > > > > >
> > > > > > > void (*func)(void);
> > > > > > > func = 0xc0000000;
> > > > > > > func();
> > > > > > 
> > > > > > Your first example writes to an area, your second is 
> > > > > > execution. IIRC, this version of the ARM architecture equates 
> > > > > > read and execute permission and so you may actually have 
> > > > > > permission to read this area and thus execute code in it.
> > 
> > User programs do not have permission to read kernel addresses.  Trying to
> > do so _should_ generate a permission fault.
> > 
> > > > > I tried reading that address (albeit on an old 2.6.28 kernel), and I get a
> > > > > segfault.
> > 
> > ... which is correct behaviour.
> > 
> > > > > Trying to execute in kernel space is the only thing that appears to hang.
> > > > > Attaching to the process in gdb, I observed that pc is always 0xc0000000
> > > > > when the process is stopped.
> > > > > 
> > > > > top accounts most of the CPU time as being consumed in the kernel.
> > > > > 
> > > > > I think what is going on here is that the kernel is catching the expected
> > > > > prefetch abort, but the handler fails to send SIGSEGV to the user process
> > > > > --- the process is resumed with the same pc and we end up in an endless
> > > > > spin.
> > 
> > Yes, that'd make sense.
> > 
> > > > diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> > > > index 9d40c34..cd4d15c 100644
> > > > --- a/arch/arm/mm/fault.c
> > > > +++ b/arch/arm/mm/fault.c
> > > > @@ -393,6 +393,9 @@ do_translation_fault(unsigned long addr, unsigned int fsr,
> > > >  	if (addr < TASK_SIZE)
> > > >  		return do_page_fault(addr, fsr, regs);
> > > >  
> > > > +	if (user_mode(regs) && addr >= TASK_SIZE)
> > > > +		goto bad_area;
> > > > +
> > > 
> > > technically, addr >= TASK_SIZE was guaranteed by the previous test
> > > on addr. The user_mode(regs) may well be a good idea, although I'm
> > > not sure if we get entered here if the kernel is attempting to access
> > > user-mode memory by forcing unpriveldged accesses.
> > > 
> > > probably best to get Russell's opinion.
> > 
> > 	if (user_mode(regs))
> > 		goto bad_area;
> > 
> > should be sufficient, since userspace should not be accessing anything
> > above TASK_SIZE, except for the exception page, which will always be
> > mapped.
> 
> Patch updated, and with comment log.
> 
> ===
> ARM: Proper prefetch abort handling on pre-ARMv6
> 
> Instruction faults on pre-ARMv6 CPUs are interpreted as
> a 'translation fault', but do_translation_fault doesn't
> handle well if user mode trying to run instruction above
> TASK_SIZE, and result in the infinite retry of that
> instruction.
> 
> Signed-off-by: Anfei Zhou <anfei.zhou@gmail.com>
> ---
>  arch/arm/mm/fault.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> index 9d40c34..8ad75e9 100644
> --- a/arch/arm/mm/fault.c
> +++ b/arch/arm/mm/fault.c
> @@ -393,6 +393,9 @@ do_translation_fault(unsigned long addr, unsigned int fsr,
>  	if (addr < TASK_SIZE)
>  		return do_page_fault(addr, fsr, regs);
>  
> +	if (user_mode(regs))
> +		goto bad_area;
> +
>  	index = pgd_index(addr);
>  
>  	/*

This patch is still not into the mainline, will you plan to apply it?

Thanks,
Anfei.

> -- 
> 1.6.4.rc1
> 

kernel virtual memory access (from app) does not generate segfault

[Russell King - ARM Linux]

On Tue, Jun 08, 2010 at 09:29:40PM +0800, anfei wrote:
> Hi Russell,
> 
> On Wed, Apr 21, 2010 at 09:11:49PM +0800, anfei wrote:
> > Patch updated, and with comment log.
> > 
> > ===
> > ARM: Proper prefetch abort handling on pre-ARMv6
> > 
> > Instruction faults on pre-ARMv6 CPUs are interpreted as
> > a 'translation fault', but do_translation_fault doesn't
> > handle well if user mode trying to run instruction above
> > TASK_SIZE, and result in the infinite retry of that
> > instruction.
> > 
> > Signed-off-by: Anfei Zhou <anfei.zhou@gmail.com>
> > ---
> >  arch/arm/mm/fault.c |    3 +++
> >  1 files changed, 3 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> > index 9d40c34..8ad75e9 100644
> > --- a/arch/arm/mm/fault.c
> > +++ b/arch/arm/mm/fault.c
> > @@ -393,6 +393,9 @@ do_translation_fault(unsigned long addr, unsigned int fsr,
> >  	if (addr < TASK_SIZE)
> >  		return do_page_fault(addr, fsr, regs);
> >  
> > +	if (user_mode(regs))
> > +		goto bad_area;
> > +
> >  	index = pgd_index(addr);
> >  
> >  	/*
> 
> This patch is still not into the mainline, will you plan to apply it?

I had, but as it isn't in the patch system, it got buried and forgotten.
Could you submit it to the patch system please?  Just emailing it in
a similar manner to that above, but with a subject of
"Proper prefetch abort handling on pre-ARMv6" and an additional
"KernelVersion: 2.6.whatever" line to the patch system should suffice.

kernel virtual memory access (from app) does not generate segfault

[anfei]

On Tue, Jun 08, 2010 at 02:36:05PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 08, 2010 at 09:29:40PM +0800, anfei wrote:
> > Hi Russell,
> > 
> > On Wed, Apr 21, 2010 at 09:11:49PM +0800, anfei wrote:
> > > Patch updated, and with comment log.
> > > 
> > > ===
> > > ARM: Proper prefetch abort handling on pre-ARMv6
> > > 
> > > Instruction faults on pre-ARMv6 CPUs are interpreted as
> > > a 'translation fault', but do_translation_fault doesn't
> > > handle well if user mode trying to run instruction above
> > > TASK_SIZE, and result in the infinite retry of that
> > > instruction.
> > > 
> > > Signed-off-by: Anfei Zhou <anfei.zhou@gmail.com>
> > > ---
> > >  arch/arm/mm/fault.c |    3 +++
> > >  1 files changed, 3 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> > > index 9d40c34..8ad75e9 100644
> > > --- a/arch/arm/mm/fault.c
> > > +++ b/arch/arm/mm/fault.c
> > > @@ -393,6 +393,9 @@ do_translation_fault(unsigned long addr, unsigned int fsr,
> > >  	if (addr < TASK_SIZE)
> > >  		return do_page_fault(addr, fsr, regs);
> > >  
> > > +	if (user_mode(regs))
> > > +		goto bad_area;
> > > +
> > >  	index = pgd_index(addr);
> > >  
> > >  	/*
> > 
> > This patch is still not into the mainline, will you plan to apply it?
> 
> I had, but as it isn't in the patch system, it got buried and forgotten.
> Could you submit it to the patch system please?  Just emailing it in
> a similar manner to that above, but with a subject of
> "Proper prefetch abort handling on pre-ARMv6" and an additional
> "KernelVersion: 2.6.whatever" line to the patch system should suffice.

Done, thanks!
Anfei.