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-next>] [day] [month] [year] [list]
Message-ID: <5491B4A8.905@amacapital.net>
Date:	Wed, 17 Dec 2014 08:51:52 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	linux-efi@...r.kernel.ogr, LKML <linux-kernel@...r.kernel.org>
Subject: EFI mixed mode + perf = rampant triple faults

I figured I should send this email before I forget about this issue:

If you run perf record across any EFI mixed mode call or otherwise
receive an NMI or MCE, the machine triple-faults.  The cause is
straightforward: there is no valid IDT when we have long mode disabled
for the duration of the EFI call.

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 controls
on intra-ring interrupts, but that shouldn't be an issue here.)

As an added benefit, this would considerably simplify the code.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ