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:	Mon, 29 Sep 2014 21:41:47 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Andy Lutomirski <luto@...capital.net>
cc:	Anish Bhatt <anish@...lsio.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	X86 ML <x86@...nel.org>, Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Sebastian Lackner <sebastian@...-team.de>
Subject: Re: [PATCH] x86 : Ensure X86_FLAGS_NT is cleared on syscall entry

On Mon, 29 Sep 2014, Andy Lutomirski wrote:
> On Mon, Sep 29, 2014 at 11:59 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> > On Mon, 29 Sep 2014, Andy Lutomirski wrote:
> >> Presumably interrupt delivery clears NT.  I haven't spotted where that's
> >> documented yet.
> >
> > Nope, that's unrelated.
> 
> If it weren't the case, then we'd be totally screwed.  Fortunately, it
> is.  I found it: SDM Volume 3 6.12.1.2 says:
> 
> (On calls to exception and interrupt
> handlers, the processor also clears the VM, RF, and NT flags in the
> EFLAGS register,
> after they are saved on the stack.)

Sorry, I misunderstood your question.

And yes on exception and interrupt entry it is cleared. Otherwise the
whole feature would not work at all ...

But that's why I'm really not worried about it. While we can mask out
the stupid bit easily, it does not provide any value except protecting
silly userspace from rightfully raised exceptions.

When I first saw that patch, I was worried about the security impact,
but after staring long enough at the SDM and the code, the only way it
can explode is when returning to user space. It cannot explode in the
kernel.

So in IA-32e it creates a #GP otherwise it falls over the return to
NULL (TSS.back_link). So what?

Thanks,

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ