diff options
| author | Ard Biesheuvel <ardb@kernel.org> | 2026-09-25 09:51:39 +0200 |
|---|---|---|
| committer | Borislav Petkov (AMD) <bp@alien8.de> | 2026-09-28 15:07:42 -0700 |
| commit | 0ffdb6c1ea44ddb40794b9c20a39b8fb30551875 (patch) | |
| tree | d0aad5be74ed60a853c43acaf55a9494b555eb22 /tools/perf/scripts/python | |
| parent | b24bc9dec9c89d01ccb675a55cda6831dc048ce9 (diff) | |
| download | linux-next-0ffdb6c1ea44ddb40794b9c20a39b8fb30551875.tar.gz linux-next-0ffdb6c1ea44ddb40794b9c20a39b8fb30551875.zip | |
x86/tdx: Share tdx_panic() with the EFI stub
Move the implementation of tdx_panic() into the source file that is
shared with the decompressor and the EFI stub.
Use memcpy() and strnlen() instead of strtomem_pad(), as the latter does
not exist in the early boot code. Avoid fortify instrumentation in the
decompressor/EFI stub by defining __NO_FORTIFY before including
tdx-shared.c
Note that __tdx_hypercall() may call __tdx_hypercall_failed() if the
hypercall returns with an error (while it should never return to begin
with). __tdx_hypercall_failed() calls the decompressor's error()
routine, which prints a message and then loops forever.
When called from the EFI stub, this error() call may attempt to use port
I/O to the default serial port rather than the TDX hypercalls which the
decompressor uses normally to print diagnostics to the console, but this
is fine: given that this situation only occurs after a catastrophic
error, and a subsequent spurious return from tdx_panic(), whether
error() uses port I/O or not is rather moot at that point, as long as it
never returns.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
Link: https://patch.msgid.link/20260925075137.44298-6-ardb@kernel.org
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions
