[PATCH] ARM: Add SWP/SWPB emulation for ARMv7 processors (v2)

Russell King - ARM Linux linux at arm.linux.org.uk
Sat Dec 19 12:28:33 EST 2009


On Sat, Dec 19, 2009 at 05:18:42PM +0000, Catalin Marinas wrote:
> On Fri, 2009-12-18 at 18:20 +0000, Russell King - ARM Linux wrote:
> > On Fri, Dec 18, 2009 at 06:04:06PM +0000, Leif Lindholm wrote:
> > > +static int swp_handler(struct pt_regs *regs, unsigned int instr)
> > > +{
> > > +     unsigned int address, destreg, data;
> > > +     unsigned int res = 0;
> > > +     long current_pid = sys_getpid();
> > 
> > Kernel functions calling system calls like this is frowned upon.  We
> > know what the current PID is - it's available from current->pid.  No
> > function call required.
> 
> Actually, current->pid together with get_task_comm() would be even more
> useful since the task may die by the time you check the running apps.

That's effectively what is being done - current->comm is effectively
get_task_comm() - get_task_comm() just copies the string out under a
lock.

For debugging of the 'current' task, the additional copy and lock are
mere overhead.

> > We can trap this case by looking at the L_PTE_MT_* bits in the pte
> > for the page we're going to be accessing - that's probably a good
> > idea to ensure that such accesses are trapped, rather than going
> > head and possibly risking silent corruption.
> 
> I wonder if there could be an exploit with Leif's current
> implementation. The LDREX/STREX pair to uncached or device memory may
> never complete. This way a user SWP to something like the frame buffer
> would lock the kernel.

That means we shouldn't consider applying it until that has been
investigated.



More information about the linux-arm-kernel mailing list