On Wed, Sep 22, 2021 at 08:40:43AM -0500, Tom Lendacky wrote:
On 9/21/21 4:58 PM, Kirill A. Shutemov wrote:
On Tue, Sep 21, 2021 at 04:43:59PM -0500, Tom Lendacky wrote:
On 9/21/21 4:34 PM, Kirill A. Shutemov wrote:
On Tue, Sep 21, 2021 at 11:27:17PM +0200, Borislav Petkov wrote:
On Wed, Sep 22, 2021 at 12:20:59AM +0300, Kirill A. Shutemov wrote:
I still believe calling cc_platform_has() from __startup_64() is totally broken as it lacks proper wrapping while accessing global variables.
Well, one of the issues on the AMD side was using boot_cpu_data too early and the Intel side uses it too. Can you replace those checks with is_tdx_guest() or whatever was the helper's name which would check whether the the kernel is running as a TDX guest, and see if that helps?
There's no need in Intel check this early. Only AMD need it. Maybe just opencode them?
Any way you can put a gzipped/bzipped copy of your vmlinux file somewhere I can grab it from and take a look at it?
You can find broken vmlinux and bzImage here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrive.goog...
Let me know when I can remove it.
Looking at everything, it is all RIP relative addressing, so those accesses should be fine.
Not fine, but waiting to blowup with random build environment change.
Your image has the intel_cc_platform_has() function, does it work if you remove that call? Because I think it may be the early call into that function which looks like it has instrumentation that uses %gs in __sanitizer_cov_trace_pc and %gs is not setup properly yet. And since boot_cpu_data.x86_vendor will likely be zero this early it will match X86_VENDOR_INTEL and call into that function.
Right removing call to intel_cc_platform_has() or moving it to cc_platform.c fixes the issue.