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: <CALCETrX86zeONHsf74yKseddXUc1BMHHAFaGKgU82HuU9+_PjQ@mail.gmail.com>
Date:	Tue, 30 Sep 2014 14:45:48 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Sebastian Lackner <sebastian@...-team.de>
Cc:	Thomas Gleixner <tglx@...utronix.de>, X86 ML <x86@...nel.org>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, 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 Tue, Sep 30, 2014 at 2:39 PM, Sebastian Lackner
<sebastian@...-team.de> wrote:
> 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 don't buy this explanation at all.  Surely Wine is responsible for
all system calls that happen.  There's only a problem when NT is set
and a system call happens.

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

This patch would make more sense if you only cleared it from the
actual regs, not the saved regs.  User code can do the latter on its
own.

It would certainly be possible to clear NT and retry IRET if IRET
fails with NT set.  This would have no overhead for anything relevant.
That would be this alternative from my 0/2 email:

 - Don't filter NT on sysenter.  Instead, filter it on EFI entry
   and modify the IRET code to retry without NT set if NT was set.

Thomas hpa, etc: any thoughts?

>
> Regards,
> Sebastian
>



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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/