linux-kernel - Re: [PATCH 1/2] x86_64,entry: Filter RFLAGS.NT on entry from userspace

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: <542B2305.9060805@fds-team.de>
Date:	Tue, 30 Sep 2014 23:39:17 +0200
From:	Sebastian Lackner <sebastian@...-team.de>
To:	Andy Lutomirski <luto@...capital.net>,
	Thomas Gleixner <tglx@...utronix.de>, X86 ML <x86@...nel.org>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>
CC:	Anish Bhatt <anish@...lsio.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Chuck Ebbert <cebbert.lkml@...il.com>, stable@...nel.org
Subject: Re: [PATCH 1/2] x86_64,entry: Filter RFLAGS.NT on entry from userspace

On 30.09.2014 21:40, Andy Lutomirski wrote:
> what would happen.  Apparently Wine sometimes does this (!), and, if
> an IRET return happens, Wine will segfault.
> 
> I think that Wine should be fixed to stop setting NT when a syscall
> happens, but handling NT more gracefully is still nice.
> 

Just to give some more background about this issue: Wine has no influence
if the NT flag is set or not - as Wine doesn't trace each individual opcode,
there is no chance to know, if a Windows program messes up the EFLAGS. This
happens in closed source Windows applications, so its not really Wines fault.

I think the current approach should be fine, but if other people prefer one of
the solutions without additional overhead on syscall entry:

At least for Wine it would also be absolutely fine, when the application would
just get a proper signal (if adding the retry IRET is too complicated). I've
attached the url to an additional example program, which shows that currently
the signal handler is unable to process such a fault, and a proof-of-concept
patch to clear the NT flags at least for the signal handler. Such a patch
doesn't fix the potential issues with EFI though.

Example program:
http://ix.io/ezl

Proof-of-concept patch:
http://ix.io/ezm

Regards,
Sebastian

--
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/