linux-kernel - Re: [PATCH] x86 : Ensure X86_FLAGS

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: <alpine.DEB.2.02.1409292152270.22082@ionos.tec.linutronix.de>
Date:	Mon, 29 Sep 2014 21:57:27 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	"H. Peter Anvin" <hpa@...or.com>
cc:	Andy Lutomirski <luto@...capital.net>,
	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>,
	Sebastian Lackner <sebastian@...-team.de>
Subject: Re: [PATCH] x86 : Ensure X86_FLAGS_NT is cleared on syscall entry

On Mon, 29 Sep 2014, H. Peter Anvin wrote:
> On 09/29/2014 12:41 PM, Thomas Gleixner wrote:
> >>
> >> 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?
> > 
> 
> How about "it's a bug, but it's not (necessarily) a security issue?"

It's a bug in user space, but as I explained it is NOT a security
issue because the only place it can explode is the return to the buggy
user space code via IRET.

If we start to use IRET in the kernel for random crap where we should
not, then its better we trap over the stupid NT bit as well.
 
> I think we should mask the bit anyway.

I tend to disagree. If we clear it there we need to consequentely
audit ALL other possibilites and if there are any we need to clear the
bit there as well. Just to make buggy user space happy?

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/