linux-kernel - Re: EFI mixed mode + perf = rampant triple faults

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: <CALCETrWOxPwoL0zo0UZMk=05uAEqgY-Xovk1=JHwbVtinx3u3w@mail.gmail.com>
Date:	Wed, 14 Jan 2015 10:27:47 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Matt Fleming <matt@...sole-pimps.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	Borislav Petkov <bp@...en8.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: EFI mixed mode + perf = rampant triple faults

On Wed, Jan 14, 2015 at 8:51 AM, Matt Fleming <matt@...sole-pimps.org> wrote:
> On Wed, 31 Dec, at 06:37:39PM, Matt Fleming wrote:
>> On Wed, 17 Dec, at 08:54:56AM, Andy Lutomirski wrote:
>> > > As far as I know, the only way to have continuously functional interrupt
>> > > handling across a long mode transition is to install an interrupt vector
>> > > table and hope that CPUs actually do something intelligent when
>> > > receiving an interrupt with LME=1, LMA=1, and PG=0.  Yuck.
>> > >
>> > > Could we get away with issuing 32-bit EFI calls in compat mode, i.e.
>> > > with a 32-bit CPL0 CS but while still in long mode?  I think that
>> > > delivery of an IST interrupt (which includes both NMI and MCE) will
>> > > correctly switch to a fully valid 64-bit state and would correctly
>> > > switch back when we execute IRET at the end.  (Am I missing some reason
>> > > that switching bitness without a privilege level change doesn't work
>> > > well?  I haven't thought of anything, other than the lack of SS/SP controls
>> > > on intra-ring interrupts, but that shouldn't be an issue here.)
>> > >
>> > > As an added benefit, this would considerably simplify the code.
>>
>> I can't immediately think of a reason that this wouldn't work, but I've
>> Cc'd more x86 folks for additional insight.
>>
>> I will schedule some time to look into this issue in the new year.
>> Thanks Andy.
>
> I finally got some time to look into this, and running with
> __KERNEL32_CS seems to work fine at runtime both with Qemu + 32-bit OVMF
> and on my ASUS T100. Manually triggering an MCE exception immediately
> before invoking the firmware service recovers gracefully.

How are you manually triggering an MCE?  I've been playing with some
MCE stuff recently, but the only reasonably reliable way I know of to
trigger an MCE is using WHEA, and I don't have a box with WHEA, and I
assume your ASUS T100 doesn't either.

>
> Where this won't work so well is at boot time before we jump to the
> kernel proper. There, we still need to restore the firmware's GDT so
> that interrupts are serviced correctly before ExitBootServices() (in
> particular, ia32 Tianocore assumes __KERNEL_CS is a 32-bit CS).

Tianocore makes assumptions about the kernel's GDT layout?  Yuck.

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