linux-kernel - Re: Domain faults when CONFIG_CPU_SW_DOMAIN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151203172708.GT8644@n2100.arm.linux.org.uk>
Date:	Thu, 3 Dec 2015 17:27:08 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Peter Rosin <peda@...ntia.se>
Cc:	"'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>,
	"'linux-arm-kernel@...ts.infradead.org'" 
	<linux-arm-kernel@...ts.infradead.org>,
	"nico@...xnic.net" <nico@...xnic.net>,
	Will Deacon <will.deacon@....com>
Subject: Re: Domain faults when CONFIG_CPU_SW_DOMAIN_PAN is enabled

On Thu, Dec 03, 2015 at 04:41:18PM +0000, Russell King - ARM Linux wrote:
> On Thu, Dec 03, 2015 at 04:12:06PM +0000, Peter Rosin wrote:
> > * uaccess_with_memcpy.c:__copy_to_user() has a mode in which it copies
> >   "non-atomically" (if faulthandler_disabled() returns 0). If a fault
> >   happens during __copy_to_user, what prevents some other thread from
> >   clobbering DACR?
> 
> See the second point above.  Moreover, if we sleep in down_read(),
> then __switch_to() reads the current DACR value and saves it in the
> thread information, and will restore that value when resuming the
> thread - even if the thread has been migrated to a different CPU.

I thought this was correct, but it isn't - that's what my original solution
did, but I think when Will reviewed it, we decided it wasn't necessary -
and it isn't necessary for every single case with the exception of this
one.  This is exactly what's going wrong: the down_read() in these paths
calls into the scheduler, which switches away.  When we come back, the
DACR value is reset by the other thread to 0x51.

There's a few ways to solve this:

1. Make the thread switching code save and restore the DACR register as
   it would do for domains.  This imposes an overhead on every single
   context switch whether or not we happen to be in this _single_
   troublesome code.  (Patch attached - as there's several, I'm attaching
   them.)

2. Add additional code to the uaccess-with-memcpy stuff to reset the
   DACR value prior to using memcpy() or memset().  (Patch attached.)

3. Make uaccess-with-memcpy depend on !CPU_SW_DOMAINS_PAN (suggested by
   Will)

4. Delete the uaccess-with-memcpy code (also suggested by Will.)

I think the best thing I can do is say... "Discuss amongst yourselves" :)

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

View attachment "umemcpy1.diff" of type "text/plain" (1596 bytes)

View attachment "umemcpy2.diff" of type "text/plain" (1780 bytes)