From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vitaly Kuznetsov Subject: Re: [PATCH] x86/kvm/vmx: don't read current->thread.{fs,gs}base of legacy tasks Date: Thu, 12 Jul 2018 11:31:41 +0200 Message-ID: <877em0ztoi.fsf@vitty.brq.redhat.com> References: <20180711173718.8850-1-vkuznets@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Cc: kvm , Paolo Bonzini , Radim Krcmar , "the arch\/x86 maintainers" , Andy Lutomirski , ldv@altlinux.org, yamato@redhat.com, LKML To: Wanpeng Li Return-path: In-Reply-To: (Wanpeng Li's message of "Thu, 12 Jul 2018 09:39:09 +0800") Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org Wanpeng Li writes: > On Thu, 12 Jul 2018 at 08:07, Vitaly Kuznetsov wrote: >> >> When we switched from doing rdmsr() to reading FS/GS base values from >> current->thread we completely forgot about legacy 32-bit userspaces which >> we still support in KVM (why?). task->thread.{fsbase,gsbase} are only >> synced for 64-bit processes, calling save_fsgs_for_kvm() and using >> its result from current is illegal for legacy processes. >> >> There's no ARCH_SET_FS/GS prctls for legacy applications. Base MSRs are, >> however, not always equal to zero. Intel's manual says (3.4.4 Segment >> Loading Instructions in IA-32e Mode): >> >> "In order to set up compatibility mode for an application, segment-load >> instructions (MOV to Sreg, POP Sreg) work normally in 64-bit mode. An >> entry is read from the system descriptor table (GDT or LDT) and is loaded >> in the hidden portion of the segment register. >> ... >> The hidden descriptor register fields for FS.base and GS.base are >> physically mapped to MSRs in order to load all address bits supported by >> a 64-bit implementation. >> " >> >> The issue was found by strace test suite where 32-bit ioctl_kvm_run test >> started segfaulting. > > Test suite: MSR switch > PASS: VM entry MSR load > PASS: VM exit MSR store > PASS: VM exit MSR load > FAIL: VM entry MSR load: try to load FS_BASE > SUMMARY: 4 tests, 1 unexpected failures > > kvm-unit-tests fails w/ and w/o the patch, maybe it is another issue, > i didn't dig further, you can have a look if you are interested in. :) The patch only changes the behavior for legacy userspaces and I can reproduce the failure on native x86_64, it is something different. I'm, however, interested so stay tuned :-) -- Vitaly