mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Daniel Verkamp <dverkamp@chromium.org>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	Tony Luck <tony.luck@intel.com>
Subject: Re: [PATCH] x86: also disable FSRM if ERMS is disabled
Date: Fri, 23 Sep 2022 19:51:33 +0200	[thread overview]
Message-ID: <Yy3yJfz213Lqo4KC@zn.tnic> (raw)
In-Reply-To: <CABVzXAk9AXj2Ns7YAh7cCA38t2sGxOEYLv-EfLCoFHr-SUQ2Mw@mail.gmail.com>

On Fri, Sep 23, 2022 at 10:25:05AM -0700, Daniel Verkamp wrote:
> Yes, we hit this in crosvm when booting the guest kernel with either
> OVMF or u-boot on an Intel 12th Gen CPU. The guest kernel boots fine
> when loaded directly (using the crosvm kernel loader and not running
> any firmware setup in the guest), but it crashes when booting with
> firmware inside the first forward memmove() after alternatives are set
> up (which happens to be in printk). I haven't gotten to the bottom of
> why exactly using firmware is causing this to be set up in an
> inconsistent way, but this is a real-world situation, not just a
> hypothetical.

Sounds like broken virt firmware or so. And if that is not an issue on
baremetal, then the virt stack should be fixed - not the kernel.

> Now that I look at it with fresh eyes again, maybe we should instead
> directly patch the memmove FSRM alternative so that the flag-set
> version just does the same jmp as the ERMS one. I can prepare a patch
> for that instead of (or in addition to) this one if that sounds
> better.

So, if the virt firmware deviates from how the real hardware behaves,
then the kernel needs no fixing.

So you'd have to figure out why is the virt firmware causing this and
not baremetal.

Then we can talk about fixes.

Thx.

-- 
Regards/Gruss,
    Boris.

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

  reply	other threads:[~2022-09-23 17:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-23  0:58 Daniel Verkamp
2022-09-23 11:13 ` Borislav Petkov
2022-09-23 17:25   ` Daniel Verkamp
2022-09-23 17:51     ` Borislav Petkov [this message]
2022-10-07 18:08       ` Daniel Verkamp
2022-10-11 11:28         ` Borislav Petkov
2022-10-11 17:09           ` Luck, Tony
2022-10-11 17:52             ` Borislav Petkov
2022-10-11 19:08               ` Luck, Tony
2022-10-11 20:56                 ` Borislav Petkov
2022-10-11 22:19                   ` Luck, Tony
2022-10-11 22:59                     ` Andrew Cooper
2023-01-04  7:43         ` Jiri Slaby
2023-01-04 11:39           ` Borislav Petkov
2023-01-14  9:19             ` Ingo Molnar
2023-01-14  9:58               ` Borislav Petkov
2023-01-16  5:26             ` Jiri Slaby
2023-01-16 21:17               ` Borislav Petkov

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=Yy3yJfz213Lqo4KC@zn.tnic \
    --to=bp@alien8.de \
    --cc=dverkamp@chromium.org \
    --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

all inboxes | Powered by JetHome®