linux-kernel - RE: [PATCH 08/10] NOTIFIER: Take over TIF_MCE_NOTIFY and implement task return notifier

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: <987664A83D2D224EAE907B061CE93D5301E7280DF7@orsmsx505.amr.corp.intel.com>
Date:	Tue, 14 Jun 2011 10:13:02 -0700
From:	"Luck, Tony" <tony.luck@...el.com>
To:	Avi Kivity <avi@...hat.com>, Borislav Petkov <bp@...64.org>
CC:	Ingo Molnar <mingo@...e.hu>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Huang, Ying" <ying.huang@...el.com>,
	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>
Subject: RE: [PATCH 08/10] NOTIFIER: Take over TIF_MCE_NOTIFY and implement
 task return notifier

>Since we can't have nested #MC (due to the IST mechanism resetting %rsp 
>and clobbering the previous invocation's stack), we have to clear MCIP 
>outside the #MC handler.  And that means irq_work_queue()
>
>(note that this changes the behaviour from memory corruption to shutdown 
>state; both suck, but one more than the other).

Hmm. We currently clear MCIP inside the handler (at the very end, but
still inside).  Deferring clearing would make sense - but we'd have to
be sure to do so a.s.a.p on all processors.  It also would change how
we look at the possibility of a process being able to run and re-execute
an instruction that causes a machine check. If we defer clearing MCIP
this won't just be annoying, it will be fatal (if any cpu hasn't yet
got to the work queue to clear MCIP).

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