[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aCMraFZ2yJQNyHf3@gmail.com>
Date: Tue, 13 May 2025 13:22:16 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Ard Biesheuvel <ardb+git@...gle.com>, linux-kernel@...r.kernel.org,
linux-efi@...r.kernel.org, x86@...nel.org,
Ard Biesheuvel <ardb@...nel.org>,
Dionna Amalie Glaze <dionnaglaze@...gle.com>,
Kevin Loughlin <kevinloughlin@...gle.com>,
Tom Lendacky <thomas.lendacky@....com>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFT PATCH v3 00/21] x86: strict separation of startup code
* Borislav Petkov <bp@...en8.de> wrote:
> On Tue, May 13, 2025 at 12:02:22PM +0200, Ingo Molnar wrote:
> > I don't intend to rush it,
>
> Thanks.
>
> > That request for testing was ignored AFAICS. It's May 13 and still
> > crickets.
>
> Not ignored - Tom and I are testing but we're busy as hell too.
Yeah, so the problem is that SEV* is hardware that basically no active
tester outside of the vendor (AMD) owns and is testing against
development trees AFAICS.
> > We also had SEV-SNP boot bugs pending since August 2024, that
> > nobody but (eventually) AMD triggered.
>
> Where?
I did a quick Git search, and here are a few examples:
For example, this commit from last summer:
6c3211796326 ("x86/sev: Add SNP-specific unaccepted memory support")
... was only fixed recently:
d54d610243a4 ("x86/boot/sev: Avoid shared GHCB page for early memory acceptance")
Or this commit from June 2024:
34ff65901735 ("x86/sev: Use kernel provided SVSM Calling Areas")
... was only fixed a few days ago:
f7387eff4bad ("x86/sev: Fix operator precedence in GHCB_MSR_VMPL_REQ_LEVEL macro")
Or this commit from June 2024:
fcd042e86422 ("x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0")
... was fixed a few weeks ago:
8ed12ab1319b ("x86/boot/sev: Support memory acceptance in the EFI stub under SVSM")
Ie. bugfix latencies here were 10+ months.
Note that two of those fixes were from Ard who is working on further
robustifying the startup code - a much needed change.
Ie. when Ard is asking for SEV-SNP testing for WIP series, which he did
10+ days ago, you should not ignore it ... or if you do ignore his
request for testing, you should not complain about the changes being
merged eventually, once they pass review & testing on non-SEV
platforms.
> > Ie. very few people outside of the vendor are testing SEV-SNP
> > AFAICS, and even vendor testing is sporadic ...
>
> Not true - SEV* testing happens on a daily basis.
If you didn't have time to personally test Ard's -v2 series since May
2, that's OK: I can merge these proposed changes in an RFT branch so
that it gets tested in the daily testing flow. [see further below for
the Git link]
In other words: please no "gatekeeping". Please don't force Ard into a
catch-22 situation where he cannot test the patches on SEV-SNP, but you
are blocking these x86 startup code changes on the grounds that they
weren't tested on SEV-SNP ...
> > Please ask AMD internally to get SEV-SNP tested more reliably.
> > Testing this -v3 series would be a good start. Hint, hint. ;-)
>
> We test everything that goes into linux-next. We haven't started
> testing unreviewed patchsets yet because we don't do that - that
> stuff is moving.
>
> So if you want to merge something, just ping me or Tom and we'll test
> it.
Here's Ard's request from May 2:
https://lore.kernel.org/r/20250504095230.2932860-25-ardb+git@google.com
"Again, I will need to lean on Tom to determine whether this breaks
SEV-SNP guest boot. As I mentioned before, I am still waiting for
SEV-SNP capable hardware to be delivered."
This request for testing was ignored AFAICS.
> But you have to give us ample time to do so - you can't merge
> something which Ard sent *on the same day*.
Sure: -v2 was sent more than 10 days ago, and the testing request was
ignored AFAICS. Do 10 days count as 'ample time'?
Anyway, to make it even lower-overhead to test these changes, I've put
the -v3 series into the WIP.x86/boot tree:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/tip.git WIP.x86/boot
Only lightly tested. Just a "boots/doesn't boot" kind of quick feedback
would be much appreciated.
Note that naturally this tree is still subject to rebasing, as review
feedback is incorporated.
Thanks!
Ingo
Powered by blists - more mailing lists