linux-kernel - Re: [PATCH v3 1/2] x86/sev/vc: fix efi runtime instruction emulation

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] [day] [month] [year] [list]

Message-ID: <aF0C-wVwXWxFjgud@gmail.com>
Date: Thu, 26 Jun 2025 10:21:15 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Gerd Hoffmann <kraxel@...hat.com>
Cc: linux-coco@...ts.linux.dev, kvm@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 1/2] x86/sev/vc: fix efi runtime instruction emulation


* Gerd Hoffmann <kraxel@...hat.com> wrote:

> In case efi_mm is active go use the userspace instruction decoder which
> supports fetching instructions from active_mm.  This is needed to make
> instruction emulation work for EFI runtime code, so it can use cpuid
> and rdmsr.
> 
> EFI runtime code uses the cpuid instruction to gather information about
> the environment it is running in, such as SEV being enabled or not, and
> choose (if needed) the SEV code path for ioport access.
> 
> EFI runtime code uses the rdmsr instruction to get the location of the
> CAA page (see SVSM spec, section 4.2 - "Post Boot").
> 
> The big picture behind this is that the kernel needs to be able to
> properly handle #VC exceptions that come from EFI runtime services.
> Since EFI runtime services have a special page table mapping for the EFI
> virtual address space, the efi_mm context must be used when decoding
> instructions during #VC handling.
> 
> Signed-off-by: Gerd Hoffmann <kraxel@...hat.com>
> ---
>  arch/x86/coco/sev/vc-handle.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/coco/sev/vc-handle.c b/arch/x86/coco/sev/vc-handle.c
> index 0989d98da130..e498a8965939 100644
> --- a/arch/x86/coco/sev/vc-handle.c
> +++ b/arch/x86/coco/sev/vc-handle.c
> @@ -17,6 +17,7 @@
>  #include <linux/mm.h>
>  #include <linux/io.h>
>  #include <linux/psp-sev.h>
> +#include <linux/efi.h>
>  #include <uapi/linux/sev-guest.h>
>  
>  #include <asm/init.h>
> @@ -178,9 +179,14 @@ static enum es_result __vc_decode_kern_insn(struct es_em_ctxt *ctxt)
>  		return ES_OK;
>  }
>  
> +/*
> + * User instruction decoding is also required for the EFI runtime. Even though
> + * EFI runtime is running in kernel mode, it uses special EFI virtual address

s/Even though EFI runtime
 /Even though the EFI runtime

> + * mappings that require the use of efi_mm to properly address and decode.
> + */
>  static enum es_result vc_decode_insn(struct es_em_ctxt *ctxt)
>  {
> -	if (user_mode(ctxt->regs))
> +	if (user_mode(ctxt->regs) || current->active_mm == &efi_mm)

Instead of open-coding that condition, we have mm_is_efi() for that.

Thanks,

	Ingo