[svsm-devel] [EXTERNAL] Re: EDK2 CAA Page Fragmented Allocation

[Gerd Hoffmann]

On Mon, May 19, 2025 at 04:07:49PM +0000, Jon Lange wrote:
> Gerd wrote:
> 
> > Well.  Linux relocates the CAA page, and I don't think there is some way for UEFI runtime services to use that.
> > First because UEFI can't figure the address of the Linux CAA page.  And second because linux wouldn't map
> > the CAA page into the efi runtime service sandbox anyway.
> 
> This is why MSR C001_F000 is defined in the SVSM specification (see
> Section 4.2 - Post Boot).  UEFI runtime services can read that MSR,
> which will result in a #VC being delivered to Linux.  The Linux #VC
> handler should resolve the #VC by supplying the address of the CAA
> page.  This will enable UEFI runtime services to obtain the address of
> the Linux CAA page so it can make SVSM calls.
> 
> It seems that Linux would have to map at least the #VC handler into
> the UEFI runtime sandbox because there is the potential for UEFI
> runtime services to cause other #VC exceptions, which must not be
> fatal to the execution of the UEFI runtime.  If Linux must do that,
> then it seems like a small additional step to map the CAA page into
> that sandbox as well.

Thanks for your hints.  Got that mostly working.

Mapping the #vc handler is not needed, I think on exceptions linux
switches to kernel context anyway.  The instruction emulation needed a
fix though so it goes fetch the faulting instruction from efi_mm
context.  Mapping the CAA page into the sandbox (aka efi_mm context) is
needed indeed.  It's done already for the ghcs pages, so I added caa
there.

Now svsm calls from uefi runtime actually land in svsm.  Progress!

Next problem is that svsm reading the caa page seems to fail.  The code
doesn't get past the calling_area.read() call in
get_and_clear_caa_request_flag(), and I have no idea why.  The linux
kernel doing the same thing with the same caa page works just fine.  And
given that svsm uses its own page mapping for the caa page I think it
should not matter whenever the call comes from linux kernel context or
efi_mm context ...

debug log:

[SVSM] ERROR: #VC handling error: Insn(DecodeOpCode)
[SVSM] ERROR: Panic on CPU[0]! COCONUT-SVSM Version: a7c20912+
[SVSM] ERROR: Info: panicked at kernel/src/cpu/idt/svsm.rs:319:13:
Failed to handle #VC from kernel-mode at RIP 0xffffff800021faf8 code: 0x0000000000000404

stack trace:

(gdb) bt ctxt.frame.rsp
#0  0xffffff80001dea39 in svsm::debug::gdbstub::svsm_gdbstub::debug_break () at kernel/src/debug/gdbstub.rs:173
#1  0xffffff8000129d13 in svsm::panic (info=0xfffffe008000b010) at kernel/src/svsm.rs:398
#2  0xffffff80002d65e0 in core::panicking::panic_fmt (fmt=...) at library/core/src/panicking.rs:75
#3  0xffffff8000195ee1 in svsm::cpu::idt::svsm::ex_handler_vmm_communication (ctxt=0xfffffe008000b4f8, vector=29) at kernel/src/cpu/idt/svsm.rs:319
#4  0xffffff80002db9cc in L64 ()
#5  0x0000000000000000 in ?? ()

context:

(gdb) print /x *ctxt
$3 = svsm::cpu::idt::common::X86ExceptionContext {ssp: 0x0, _padding: [0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
    0x0], regs: svsm::cpu::registers::X86GeneralRegs {r15: 0x0, r14: 0x0, r13: 0x0, r12: 0x0, r11: 0xfffffe008000bc90, r10: 0x8, r9: 0x40, r8: 0x1, rbp: 0xfffffe008000b610, rdi: 0xfffffe008000b670, rsi: 0xffffff0000002000, rdx: 0xfffffe008000b670, rcx: 0x8, rbx: 0x0, rax: 0xfffffe008000b698}, error_code: 0x404, frame: svsm::cpu::registers::X86InterruptFrame {rip: 0xffffff800021faf8, cs: 0x8, flags: 0x10096, rsp: 0xfffffe008000b5b8, ss: 0x0}}

exception raised here:

(gdb) disas ctxt.frame.rip
Dump of assembler code for function _ZN4svsm2mm8guestmem10copy_bytes17hb74ce3bae1bdb91fE:
   0xffffff800021fad0 <+0>:     push   %rbp
   0xffffff800021fad1 <+1>:     mov    %rsp,%rbp
   0xffffff800021fad4 <+4>:     sub    $0x58,%rsp
   0xffffff800021fad8 <+8>:     mov    %rdx,-0x58(%rbp)
   0xffffff800021fadc <+12>:    mov    %rdi,%rax
   0xffffff800021fadf <+15>:    mov    -0x58(%rbp),%rdi
   0xffffff800021fae3 <+19>:    mov    %rax,-0x50(%rbp)
   0xffffff800021fae7 <+23>:    mov    %rax,-0x48(%rbp)
   0xffffff800021faeb <+27>:    mov    %rsi,-0x18(%rbp)
   0xffffff800021faef <+31>:    mov    %rdi,-0x10(%rbp)
   0xffffff800021faf3 <+35>:    mov    %rcx,-0x8(%rbp)
   0xffffff800021faf7 <+39>:    cld
   0xffffff800021faf8 <+40>:    rep movsb %ds:(%rsi),%es:(%rdi)

take care,
  Gerd