Messages in this thread | | | Date | Fri, 12 Jan 2024 15:17:25 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [RFC PATCH v2] x86/sev: enforce RIP-relative accesses in early SEV/SME code |
| |
On Thu, Jan 11, 2024 at 10:36:50PM +0000, Kevin Loughlin wrote: > SEV/SME code can execute prior to page table fixups for kernel > relocation. However, as with global variables accessed in > __startup_64(), the compiler is not required to generate RIP-relative > accesses for SEV/SME global variables, causing certain flavors of SEV > hosts and guests built with clang to crash during boot. > > While an attempt was made to force RIP-relative addressing for certain > global SEV/SME variables via inline assembly (see snp_cpuid_get_table() > for example), RIP-relative addressing must be pervasively-enforced for > SEV/SME global variables when accessed prior to page table fixups. > > __startup_64() already handles this issue for select non-SEV/SME global > variables using fixup_pointer(), which adjusts the pointer relative to > a `physaddr` argument. To avoid having to pass around this `physaddr` > argument across all functions needing to apply pointer fixups, this > patch introduces the macro GET_RIP_RELATIVE_PTR() (an abstraction of > the existing snp_cpuid_get_table()), which generates an RIP-relative > pointer to a passed variable. Similarly, PTR_TO_RIP_RELATIVE_PTR() is > introduced to fixup an existing pointer value with RIP-relative logic.
Can we replace existing fixup_pointer() (and other fixup_*()) with the new thing? I don't think we need two confusing things for the same function.
Also, is there any reason why GET_RIP_RELATIVE_PTR() and PTR_TO_RIP_RELATIVE_PTR() have to be macros? Inline functions would be cleaner.
-- Kiryl Shutsemau / Kirill A. Shutemov
| |