linux-kernel - Re: RFC: Petition Intel/AMD to add POPF

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: <CA+55aFxykhpzknQ=B+TQpPWRyr6cRP1u0X1Tdr7VG=V5UZGgLA@mail.gmail.com>
Date:	Wed, 17 Aug 2016 12:29:19 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Denys Vlasenko <dvlasenk@...hat.com>,
	Sara Sharon <sara.sharon@...el.com>,
	Dan Williams <dan.j.williams@...el.com>,
	Christian König <christian.koenig@....com>,
	Vinod Koul <vinod.koul@...el.com>,
	Alex Deucher <alexander.deucher@....com>,
	Johannes Berg <johannes.berg@...el.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Andy Lutomirski <luto@...nel.org>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	Ingo Molnar <mingo@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Adrian Hunter <adrian.hunter@...el.com>
Subject: Re: RFC: Petition Intel/AMD to add POPF_IF insn

On Wed, Aug 17, 2016 at 12:13 PM, Andy Lutomirski <luto@...capital.net> wrote:
>
> It wouldn't surprise me if that were easier said than done.  popf
> potentially changes AC, and AC affects address translation.

Rigth. A lot of magical flags are in eflags, and popf *may* change them.

But that's why it's slow today. The popf microcode probably
unconditionally serializes things exactly because "things may change".
And the interrupt flag actually *is* pretty special too, in some
respects more so than AC (because it needs to serialize with any
pending interrupts).

And the microcode probably already has code that says "let's handle
the easy case quickly", where the easy case is "only the arithmetic
flags changed".

The arithmetic flags are special anyway, because they aren't actually
physically in the same register any more, but are separately tracked
and renamed etc.

But I'm sure Intel already treats IF specially in microcode, because
IF is really special in other ways (VIF handling in vm86 mode, but
also modern virtualization).

Yes, intel people tend to be afraid of the microcode stuff, and
generally not touch it. But the good news about popf is that is isn't
a serializing instruction, so it really *could* be optimized pretty
aggressively. And it does have to check for pending interrupts (and
*clearing* IF in particular needs to make sure that there isn't some
pending interrupt that the CPU is about to react to).

So it's not trivial. But the "enable interrupts" case for popf is
actually easier for hardware than the disable case from a serializing
standpoint, and I suspect the ucode doesn't take advantage of that
right now, and it's all just fairly unoptimized microcode.

                Linus