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
| ||
|
Date: Wed, 14 Sep 2022 05:03:59 -0700 From: Dave Hansen <dave.hansen@...el.com> To: Peter Gonda <pgonda@...gle.com>, Adam Dunlap <acdunlap@...gle.com> Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, the arch/x86 maintainers <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>, Nathan Chancellor <nathan@...nel.org>, Nick Desaulniers <ndesaulniers@...gle.com>, Tom Rix <trix@...hat.com>, "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, Sean Christopherson <seanjc@...gle.com>, Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@...ux.intel.com>, Andi Kleen <ak@...ux.intel.com>, Ben Dooks <ben-linux@...ff.org>, LKML <linux-kernel@...r.kernel.org>, llvm@...ts.linux.dev, Jacob Xu <jacobhxu@...gle.com>, Alper Gun <alpergun@...gle.com>, Marc Orr <marcorr@...gle.com> Subject: Re: [PATCH v2 RESEND] x86/asm: Force native_apic_mem_read to use mov On 9/14/22 04:13, Peter Gonda wrote: > On Thu, Sep 8, 2022 at 6:05 PM Adam Dunlap <acdunlap@...gle.com> wrote: >> Previously, when compiled with clang, native_apic_mem_read gets inlined >> into __xapic_wait_icr_idle and optimized to a testl instruction. When >> run in a VM with SEV-ES enabled, it attempts to emulate this >> instruction, but the emulator does not support it. Instead, use inline >> assembly to force native_apic_mem_read to use the mov instruction which >> is supported by the emulator. > This seems to be an issue with the SEV-ES in guest #VC handler's > "emulator" right? No. It's not just an SEV-ES thing. It's a problem for TDX and _probably_ a problem for normal virtualization where it's a host-side issue. Kirill wrote a lot of great background information in here: > https://lore.kernel.org/all/164946765464.4207.3715751176055921036.tip-bot2@tip-bot2/ So, the question is not "should we extend the MMIO instruction decoders to handle one more instruction?". It is "should we extend the MMIO decoders to handle *ALL* memory read instructions?" That's an even more emphatic "NO". readl() seems to be the right thing to do. Also, Dear TDX, SEV and virt folks: please look for more of these. They're going to bite you sooner or later. You should have caught this one before now.
Powered by blists - more mailing lists