Re: USB mass storage and ARM cache coherency
From: Russell King - ARM Linux
Date: Wed Mar 03 2010 - 14:45:43 EST
On Wed, Mar 03, 2010 at 03:54:37PM +0530, James Bottomley wrote:
> On Wed, 2010-03-03 at 09:36 +0000, Russell King - ARM Linux wrote:
> > James, that's a pipedream. If you have a processor which doesn't support
> > NX, then the kernel marks all regions executable, even if the app only
> > asks for RW protection.
> I'm not talking about what the processor supports ... I'm talking about
> what the user sets on the VMA. My point is that the kernel only has
> responsibility in specific situations ... it's those paths we do the I/D
> coherency on.
You may not be talking about what the processor supports, but it is
> > You end up with the protection masks always having VM_EXEC set in them,
> > so there's no way to distinguish from the kernel POV which pages are
> > going to be executed and those which aren't.
> I think you're talking about the pte page flags, I'm talking about the
> VMA ones above.
No, I'm talking about the VMA ones.
if ((prot & PROT_READ) && (current->personality & READ_IMPLIES_EXEC))
if (!(file && (file->f_path.mnt->mnt_flags & MNT_NOEXEC)))
prot |= PROT_EXEC;
/* Do simple checking here so the lower-level routines won't have
* to. we assume access permissions have been handled by the open
* of the memory object, so we don't do any here.
vm_flags = calc_vm_prot_bits(prot) | calc_vm_flag_bits(flags) |
mm->def_flags | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC;
calc_vm_prot_bits(unsigned long prot)
return _calc_vm_trans(prot, PROT_READ, VM_READ ) |
_calc_vm_trans(prot, PROT_WRITE, VM_WRITE) |
_calc_vm_trans(prot, PROT_EXEC, VM_EXEC) |
So, if you have a CPU which does not support NX, then READ_IMPLIES_EXEC
is set in the personality. That forces PROT_EXEC for anything with
PROT_READ, which in turn forces VM_EXEC.
> I'm not saying the common path (faulting in text sections) is the
> responsibility of user space. I'm saying the uncommon path, write
> modification of binaries, is. So the kernel only needs to worry about
> the ordinary text fault path.
What I'm saying is that you can't always tell the difference between
what's an executable page and what isn't in the kernel. On NX-incapable
CPUs, the kernel treats *all* readable pages as executable, and there's
no way to tell from the VMA or page protection flags that this isn't
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/