mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Jue Wang <juew@google.com>
Cc: "Luck, Tony" <tony.luck@intel.com>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86/mm: Don't try to change poison pages to uncacheable in a guest
Date: Mon, 18 May 2020 15:48:13 +0200	[thread overview]
Message-ID: <20200518134813.GC25034@zn.tnic> (raw)
In-Reply-To: <CAPcxDJ6f3pBpwiR9nvXN_g_HBa1RAMG+aOmgfXLFT6aZ9HQn3w@mail.gmail.com>

Hi,

lemme try to reply to three emails at once.

First of all, the two of you: pls do not top-post.

On Sat, May 16, 2020 at 6:52 PM Luck, Tony <tony.luck@intel.com> wrote:
> But the guest isn’t likely to do the right thing with a page fault.
> The guest just accessed a page that it knows is poisoned (VMM just told
> it once that it was poisoned). There is no reason that the VMM should
> let the guest actually touch the poison a second time. But if the guest
> does, then the guest should get the expected response. I.e. another
> machine check.

So Jue says below that the VMM has unmapped the guest page from the EPT.
So the guest cannot touch the poison anymore.

How is then possible for the guest to touch it again if the page is not
mapped anymore?

The guest should get a #PF when the page is unmapped and cause a new
page to be mapped.

On Sun, May 17, 2020 at 07:36:00AM -0700, Jue Wang wrote:
> The stack is from guest MCE handler's processing of the first MCE injected.

Aha, so you've flipped the functions order in the trace. It all starts
at

  set_mce_nospec(m->addr >> PAGE_SHIFT);

Now it makes sense.

> Note before the first MCE is injected into guest (i.e., after the host MCE
> handler successfully finished MCE handling and notified VMM via SIGBUS with
> BUS_MCEERR_AR), VMM unmaps the guest page from EPT.

Ok, good.

> The guest MCE handler finished the "normal" MCE handling and recovery
> (memory_failure() in mm/memory_failure.cc) successfully, it's the aftermath
> below leading to the stack trace:
> https://github.com/torvalds/linux/blob/5a9ffb954a3933d7867f4341684a23e008d6839b/arch/x86/kernel/cpu/mce/core.c#L1101

On Sun, May 17, 2020 at 08:33:00AM -0700, Jue Wang wrote:
> In other words, it's the *do_memory_failure -> set_mce_nospec*  flow of
> guest MCE handler acting on the *first* MCE injection. As a result, the
> guest panics and resets *whenever* there is an MCE injected, even when the
> injected MCE is recoverable.

So IIUC that set_mce_nospec() thing should check whether m->addr is
mapped first and only then mark it _uc and whatever monkey business it
does. Not this blanket

  if am I a guest?

test.

Imagine a hypervisor which doesn't set X86_FEATURE_HYPERVISOR, i.e.,
CPUID(1)[EDX, bit 31]?

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

  parent reply	other threads:[~2020-05-18 13:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-05 18:46 Tony Luck
2020-05-16  6:54 ` Borislav Petkov
2020-05-16 14:47   ` Luck, Tony
2020-05-16 15:02     ` Borislav Petkov
2020-05-17  1:52       ` Luck, Tony
     [not found]         ` <CAPcxDJ50pbuTbittyvPwKq1uUT8q8jJ+dHH8rCug8a1DDZXVYw@mail.gmail.com>
     [not found]           ` <CAPcxDJ6f3pBpwiR9nvXN_g_HBa1RAMG+aOmgfXLFT6aZ9HQn3w@mail.gmail.com>
2020-05-18 13:48             ` Borislav Petkov [this message]
2020-05-18 15:36               ` Luck, Tony
2020-05-18 16:55                 ` Borislav Petkov
2020-05-18 18:26                   ` Luck, Tony
2020-05-18 19:20                     ` Dan Williams
2020-05-19  5:22                     ` Sean Christopherson
2020-05-19  8:50                     ` Borislav Petkov
2020-05-20 16:35                       ` [PATCH v2] x86/mm: Change so poison pages are either unmapped or marked uncacheable Luck, Tony
2020-05-25 11:00                         ` [tip: ras/core] x86/{mce,mm}: " tip-bot2 for Tony Luck
2020-05-25 20:40                           ` Borislav Petkov
2020-05-26 17:37                             ` Luck, Tony
     [not found]                               ` <CAPcxDJ5arJojbY4pzOvYh=waSPd3X_JJb1_PSuzd+jQ0qbvFsA@mail.gmail.com>
     [not found]                                 ` <CAPcxDJ54EgX-SaDV=Lm+a2-43O68LhomyYfYdCDz38HGJCkh7g@mail.gmail.com>
2020-05-26 19:46                                   ` Borislav Petkov
2020-05-26 19:56                         ` [tip: ras/core] x86/{mce,mm}: Unmap the entire page if the whole page is affected and poisoned tip-bot2 for Tony Luck
2020-05-19  5:04                   ` [PATCH] x86/mm: Don't try to change poison pages to uncacheable in a guest Sean Christopherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200518134813.GC25034@zn.tnic \
    --to=bp@alien8.de \
    --cc=dan.j.williams@intel.com \
    --cc=juew@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome