linux-kernel - Re: [PATCH 1/4] x86: entry.S: tidy up several suboptimal insns

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: <20150225093942.GA6676@gmail.com>
Date:	Wed, 25 Feb 2015 10:39:42 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Borislav Petkov <bp@...en8.de>,
	Oleg Nesterov <oleg@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Alexei Starovoitov <ast@...mgrid.com>,
	Will Drewry <wad@...omium.org>,
	Kees Cook <keescook@...omium.org>, X86 ML <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] x86: entry.S: tidy up several suboptimal insns

* H. Peter Anvin <hpa@...or.com> wrote:

> > So could we just zap the high 32 bits of RAX early in 
> > the entry code, and then from that point on we could 
> > both use 32-bit ops and won't have to remember the 
> > possibility either?
> 
> We do that, [...]

Ok, indeed, so in ia32_sysenter_target() we have:

        movl    %eax, %eax

> [...] but people keep "optimizing" the zero extend away. 
> [...]

Possibly because there's not a single comment near that 
code explaining the importance of that line. But nobody 
will get a change past me with such a warning next to the 
line.

> [...]  We have had this cause a wide-open security hole 
> twice already.  So the extra REX prefix is a cheap cost 
> to avoid this happen again.

But since we already zap the high bits, there's no point in 
doing 64-bit compares...

Just make sure the high zero bit clearing is there and is 
never removed.

So in that sense the changes are correct, even in the 
security robustness sense.

Furthermore, with the masking suggestion I made in the 
previous mail it's moot as we can solve both problems: 
64-bit uses of RAX will become correct as well, and it
will be a bit faster as well.

Hm?

Thanks,

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