linux-kernel - Re: [PATCH v7 05/22] x86/sev: Move GHCB page based HV communication out of startup code

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]

Message-ID: <CAMj1kXFHrkY9R8xjrB_PFqswc2yOHGpPfEBq5WZ0rH_vbo55Mw@mail.gmail.com>
Date: Sun, 31 Aug 2025 14:30:29 +0200
From: Ard Biesheuvel <ardb@...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, Ingo Molnar <mingo@...nel.org>, 
	Kevin Loughlin <kevinloughlin@...gle.com>, Tom Lendacky <thomas.lendacky@....com>, 
	Josh Poimboeuf <jpoimboe@...nel.org>, Peter Zijlstra <peterz@...radead.org>, 
	Nikunj A Dadhania <nikunj@....com>
Subject: Re: [PATCH v7 05/22] x86/sev: Move GHCB page based HV communication
 out of startup code

On Sun, 31 Aug 2025 at 13:15, Borislav Petkov <bp@...en8.de> wrote:
>
> On Sun, Aug 31, 2025 at 12:56:41PM +0200, Ard Biesheuvel wrote:
> > OK it appears I've fixed it in the wrong place: the next patch adds
> > back the definition of has_cpuflag() so I squashed that hunk into the
> > wrong patch, it seems.
>
> The real question is - and I'm sceptical - whether the startup code runs too
> early for boot_cpu_has(). And how is the startup code going to call
> boot_cpu_has().
>
> /me builds .s
>
> Aha, so it gets converted into a boot_cpu_data access:
>
> # arch/x86/boot/startup/sev-shared.c:662:       if (validate && !has_cpuflag(X86_FEATURE_COHERENCY_SFW_NO))
>         testb   %r13b, %r13b    # validate
>         je      .L46    #,
> # ./arch/x86/include/asm/bitops.h:206:          (addr[nr >> _BITOPS_LONG_SHIFT])) != 0;
>         movq    80+boot_cpu_data(%rip), %rax    # MEM[(const volatile long unsigned int *)&boot_cpu_data + 80B], _15
> # arch/x86/boot/startup/sev-shared.c:662:       if (validate && !has_cpuflag(X86_FEATURE_COHERENCY_SFW_NO))
>
> But former question remains: AFAIK, you want to run the startup code waaay
> earlier, before we do identify_boot_cpu() which prepares boot_cpu_data, right?
>

I suppose that in this particular case, things work out fine because
calling sev_evict_cache() unnecessarily is harmless. But I agree that
in general, relying on CPU flags in code that may be called this early
is not great.

Perhaps this conditional should be moved into the caller instead
(early_set_pages_state()), and early callers from inside the startup
code should call sev_evict_cache() unconditionally?