linux-kernel - Re: [PATCH v2 1/1] arch/fault: don't print logs for pte marker poison errors

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]

Date: Wed, 15 May 2024 12:19:16 -0700
From: Axel Rasmussen <axelrasmussen@...gle.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Oscar Salvador <osalvador@...e.de>, Andrew Morton <akpm@...ux-foundation.org>, 
	Andy Lutomirski <luto@...nel.org>, "Aneesh Kumar K.V" <aneesh.kumar@...nel.org>, 
	Christophe Leroy <christophe.leroy@...roup.eu>, Dave Hansen <dave.hansen@...ux.intel.com>, 
	David Hildenbrand <david@...hat.com>, "H. Peter Anvin" <hpa@...or.com>, Helge Deller <deller@....de>, 
	Ingo Molnar <mingo@...hat.com>, 
	"James E.J. Bottomley" <James.Bottomley@...senpartnership.com>, John Hubbard <jhubbard@...dia.com>, 
	Liu Shixin <liushixin2@...wei.com>, "Matthew Wilcox (Oracle)" <willy@...radead.org>, 
	Michael Ellerman <mpe@...erman.id.au>, Muchun Song <muchun.song@...ux.dev>, 
	"Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>, Nicholas Piggin <npiggin@...il.com>, 
	Peter Xu <peterx@...hat.com>, Peter Zijlstra <peterz@...radead.org>, 
	Suren Baghdasaryan <surenb@...gle.com>, Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org, 
	linux-mm@...ck.org, linux-parisc@...r.kernel.org, 
	linuxppc-dev@...ts.ozlabs.org, x86@...nel.org
Subject: Re: [PATCH v2 1/1] arch/fault: don't print logs for pte marker poison errors

On Wed, May 15, 2024 at 11:33 AM Borislav Petkov <bp@...en8.de> wrote:
>
> On Wed, May 15, 2024 at 10:33:03AM -0700, Axel Rasmussen wrote:
> > Right, the goal is to still have the process get a SIGBUS, but to
> > avoid the "MCE error" log message. The basic issue is, unprivileged
> > users can set these markers up, and thereby completely spam up the
> > log.
>
> What is the real attack scenario you want to protect against?
>
> Or is this something hypothetical?

An unprivileged process can allocate a VMA, use the userfaultfd API to
install one of these PTE markers, and then register a no-op SIGBUS
handler. Now it can access that address in a tight loop, generating a
huge number of kernel log messages. This can e.g. bog down the system,
or at least drown out other important log messages.

For example the userfaultfd selftest does something similar to this to
test that the API works properly. :)

Even in a non-contrived / non-malicious case, use of this API could
have similar effects. If nothing else, the log message can be
confusing to administrators: they state that an MCE occurred, whereas
with the simulated poison API, this is not the case; it isn't a "real"
MCE / hardware error.

>
> > That said, one thing I'm not sure about is whether or not
> > VM_FAULT_SIGBUS is a viable alternative (returned for a new PTE marker
> > type specific to simulated poison). The goal of the simulated poison
> > feature is to "closely simulate" a real hardware poison event. If you
> > live migrate a VM from a host with real poisoned memory, to a new
> > host: you'd want to keep the same behavior if the guest accessed those
> > addresses again, so as not to confuse the guest about why it suddenly
> > became "un-poisoned".
>
> Well, the recovery action is to poison the page and the process should
> be resilient enough and allocate a new, clean page which doesn't trigger
> hw poison hopefully, if possible.
>
> It doesn't make a whole lotta sense if poison "remains". Hardware poison
> you don't want to touch a second time either - otherwise you might
> consume that poison and die.

In the KVM use case, the host can't just allocate a new page, because
it doesn't know what the guest might have had stored there. Best we
can do is propagate the poison into the guest, and let the guest OS
deal with it as it sees fit, and mark the page poisoned on the host. I
don't disagree the guest *shouldn't* reaccess it in this case. :) But
if it did, it should get another poison event just as you say.

And, live migration between physical hosts should be transparent to
the guest. So if the guest gets a poison, and then we live migrate it,
and then it accesses that address again, it should likewise get
another poison event, just as before. Even though the underlying
physical memory is *not* poisoned on the new host machine.

So the use case is, after live migration, we install one of these PTE
markers to simulate a poison event in case the address is accessed
again. But since it isn't *really* a hardware error on the new host,
no reason to spam the host kernel log when / if this occurs.

>
> --
> Regards/Gruss,
>     Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette