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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140521214845.GG25130@pd.tnic>
Date:	Wed, 21 May 2014 23:48:45 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	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>,
	Tony Luck <tony.luck@...el.com>
Subject: Re: [RFC] x86_64: A real proposal for iret-less return to kernel

On Wed, May 21, 2014 at 02:35:59PM -0700, Andy Lutomirski wrote:
> If RIPV is set but we interrupted *kernel* code, SIGBUS doesn't seem
> like the right solution anyway.
>
> Are there any machine check exceptions for which it makes sense to
> continue right where we left off without a signal?  Is CMIC such a
> beast?  Can CMIC be delivered when interrupts are off?

I think you mean CMCI and that's not even reported with a MCE exception
- there's a separate APIC interrupt for that.

I think this signal thing is for killing processes which have poisoned
memory but this memory can contained within that process and the
physical page frame can be poisoned so that it doesn't get used ever
again. In any case, this is an example for an uncorrectable error which
needs action from us but doesn't necessarily have to kill the whole
machine.

This is supposed to be more graceful instead of consuming the corrupted
data and sending it out to disk.

But sending signals from #MC context is definitely a bad idea. I think
we had addressed this with irq_work at some point but my memory is very
hazy.

@Tony: this is something we need to take a look at soonish.

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