linux-kernel - Re: Sanitize FPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task)

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]

Date:	Fri, 03 Jan 2014 23:07:57 +0000
From:	halfdog <me@...fdog.net>
To:	"H. Peter Anvin" <hpa@...or.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Sanitize FPU-state when switching tasks (was sanitize CPU-state
 when switching from virtual-8086 mode to other task)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

H. Peter Anvin wrote:
> On 12/31/2013 11:21 AM, Konrad Rzeszutek Wilk wrote:
>> 
>> So, I am wondering if this is related to " x86/fpu: CR0.TS should
>> be set before trap into PV guest's #NM exception handle" which
>> does have a similar pattern - you do enough of the task switches
>> and the FPU is screwed.
>> 
>> See
>> http://mid.gmane.org/1383720072-6242-1-git-send-email-gaoyang.zyh@taobao.com
>>
>>
>> 
(I thought there was a thread about this on LKML too but I can't
>> find it).
> 
> That would be a bug in Xen, so I guess you're surmising a similar
> bug in VirtualBox?

Not sure on that yet, but the whole thing is getting even more
funnier, the longer I can play with it. Here is some more information
from my latest tests:

* Although first observed with virtual-8086 mode, the bug is not
specific to virtual-8086 mode, it can be triggered with normal x86
userspace code also, even with better reproducibility.

* It seems, that when changing the FPU control word with "fstcw" just
before exit of the process, then another process could suffer when
doing __do_switch

* By having two rogue processes writing data to each other via a
socket, time and code-position of OOPS can be influenced.

* When deactivating mmap_min_addr, the NULL-dereferences during
task-switch are exploitable, but I did not get full ring-0 code
execution yet, putting EIP to the NULL-seg seem to have failed,
perhaps wrong RPL? Hoping to fix that during next days.

You can find the new improved test code at [1].

hd

[1]
http://www.halfdog.net/Security/2013/Vm86SyscallTaskSwitchKernelPanic/FpuStateTaskSwitchOops.c


- -- 
http://www.halfdog.net/
PGP: 156A AE98 B91F 0114 FE88  2BD8 C459 9386 feed a bee
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlLHQrwACgkQxFmThv7tq+4C+wCfZ0a0LhaJqI7DW78ZFGbnzIyu
6H8AnROrUklhvdbAGV5+7/ELEzPikU7T
=jKjH
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/