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: <4DF76586.1090308@redhat.com>
Date:	Tue, 14 Jun 2011 16:43:34 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Borislav Petkov <bp@...64.org>
CC:	Tony Luck <tony.luck@...el.com>, 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

On 06/14/2011 04:33 PM, Borislav Petkov wrote:
> >
> >  Even with mce ->  irq_work ->  rt thread, we're unlikely to return to
> >  the task as the rt thread will displace the task. It may be migrated
> >  to an idle cpu, but even then we may be able to drop the page before
> >  it gets back to userspace.
>
> This doesn't give you the guarantee that the realtime task manages to
> unmap the page from all pagetables before another process running on
> another core accesses it.

Right, it's not about a guarantee, it's about maintaining decent 
performance.

> I think your previous suggestion of making the memory failure handling
> code reentrant would cover all holes.

I think it's required, yes.

Since we can't have nested #MC (due to the IST mechanism resetting %rsp 
and cloberring 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).

> Even marking all processes mapping a faulty page STOPPED or
> UNINTERRUPTIBLE won't work in all cases since you have to go out and
> find which those processes are. And this is what the rt thread will do.

Yes.

-- 
error compiling committee.c: too many arguments to function

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