linux-kernel - Re: [RFC] x86_64: A real proposal for iret-less return to kernel

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: <20140521230202.GA28950@pd.tnic>
Date:	Thu, 22 May 2014 01:02:02 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	"Luck, Tony" <tony.luck@...el.com>, Jiri Kosina <jkosina@...e.cz>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Andi Kleen <andi@...stfloor.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>
Subject: Re: [RFC] x86_64: A real proposal for iret-less return to kernel

On Wed, May 21, 2014 at 03:52:16PM -0700, Andy Lutomirski wrote:
> I'm suggesting that you re-enable interrupts and do the work in
> do_machine_check. I think it'll just work. It might pay to set a flag
> so that you panic very loudly if do_machine_check recurses.

And that might happen very likely if we're trying to poison a page which
is shared by a couple of processes' mm's and some process on some cpu
starts touching it.

So keeping all cpus in a holding pattern is much more safe, IMO. (#MC is
broadcasted on Intel, I'm sure you know).

And even if it made sense, why go the trouble? To shorten the time we're
in the MCE handler? Well, if we spend too much time in it, then the box
is dying anyway. On a normal, healthy hw, do_machine_check doesn't run.

:-)

> I suspect that, if the hardware is generating machine checks while
> doing memory poisoning, the hardware is broken enough that even
> panicking might not work, though :)

Yeah, in such cases, they tend to escalate to fatal errors very fast so
we panic right on the spot.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/