linux-kernel - Re: [PATCH] [13/16] HWPOISON: The high level memory error handler in the VM v5

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] [day] [month] [year] [list]

Message-ID: <20090612095811.GA25568@one.firstfloor.org>
Date:	Fri, 12 Jun 2009 11:58:11 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Hugh Dickins <hugh.dickins@...cali.co.uk>
Cc:	Nick Piggin <npiggin@...e.de>, Andi Kleen <andi@...stfloor.org>,
	riel@...hat.com, chris.mason@...cle.com, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	fengguang.wu@...el.com
Subject: Re: [PATCH] [13/16] HWPOISON: The high level memory error handler in the VM v5

On Tue, Jun 09, 2009 at 05:05:53PM +0100, Hugh Dickins wrote:
> To me, it's just another layer of complexity and maintenance burden
> that one special-interest group is imposing upon mm, and I can't
> keep up with it myself.

Thanks for the kind words.
> 
> However, if I'm interpreting these extracts correctly, the whole
> thing looks very misguided to me.  Are we really going to kill any
> process that has a cousin who might once have mapped the page that's
> been found hwpoisonous?  The hwpoison secret police are dangerously
> out of control, I'd say.

What do you mean with once? It's a not yet afaik?

The not yet was intentional for early kill mode -- the main reason
for that is KVM guests where it should mimic the hardware behaviour
that you report a future memory corruption, so that the guest
takes step to never access it. So even if the access
to the bad page is in the future as long as the process
has theoretical access it should be killed.

In late kill modus that's different of course.

> 
> The usual use of rmap lookup loops is to go on to look into the page
> table to see whether the page is actually mapped: I see no attempt
> at that here, just an assumption that anyone on the list is guilty
> of mapping the page and must be killed.  And even if it did go on

Yes that's intentional.

> 
> At least in the file's prio_tree case, we'll only be killing those
> who mmapped the range which happens to include the page.  But in the
> anon case, remember the anon_vma is just a bundle of "related" vmas
> outside of which the page will not be found; so if one process got a
> poisonous page through COW, all the other processes which happen to
> be sharing that anon_vma through fork or through adjacent merging,
> are going to get killed too.

You're right the COW case is a bit of a problem, we don't distingush
that.  Perhaps that can be easily checked, but even if we kill
a bit too much it's still better than killing too little. I don't think it's
as big a problem as you claim.

> I think a much more sensible approach would be to follow the page
> migration technique of replacing the page's ptes by a special swap-like
> entry, then do the killing from do_swap_page() if a process actually
> tries to access the page.

That's what late kill modus does (see the patch description/comment on
top of file), but it doesn't have the right semantics for KVM.
It's still used for a few cases by default, e.g. for the swap cache.


-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only.
--
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/