linux-kernel - Re: [PATCH v11 7/9] KVM: X86: Add userspace access interface for CET MSRs

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 26 Apr 2020 23:23:55 +0800
From:   Yang Weijiang <weijiang.yang@...el.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Yang Weijiang <weijiang.yang@...el.com>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, sean.j.christopherson@...el.com,
        jmattson@...gle.com, yu.c.zhang@...ux.intel.com
Subject: Re: [PATCH v11 7/9] KVM: X86: Add userspace access interface for CET
 MSRs

On Sat, Apr 25, 2020 at 05:31:59PM +0200, Paolo Bonzini wrote:
> On 26/03/20 09:18, Yang Weijiang wrote:
> > There're two different places storing Guest CET states, states
> > managed with XSAVES/XRSTORS, as restored/saved
> > in previous patch, can be read/write directly from/to the MSRs.
> > For those stored in VMCS fields, they're access via vmcs_read/
> > vmcs_write.
> > 
> > To correctly read/write the CET MSRs, it's necessary to check
> > whether the kernel FPU context switch happened and reload guest
> > FPU context if needed.
> 
> I have one question here, it may be just a misunderstanding.
> 
> As I understand it, the PLx_SSP MSRs are only used when the current
> privilege level changes; the processor has a hidden SSP register for the
> current privilege level, and the SSP can be accessed via VMCS only.
>
> These patches do not allow saving/restoring this hidden register.
> However, this should be necessary in order to migrate the virtual
> machine.  The simplest way to plumb this is through a KVM-specific MSR
> in arch/x86/include/uapi/asm/kvm_para.h.  This MSR should only be
> accessible to userspace, i.e. only if msr_info->host_initiated.
Thanks for raising the issue!
I checked SDM again, yes, it's neccessary to save the current SSP for
migration case, I'll follow your advice to add it as custom MSR.
 
> Testing CET in the state-test selftest is a bit hard because you have to
> set up S_CET and the shadow stack, but it would be great to have a
> separate test similar to tools/testing/selftests/x86_64/smm_test.  It's
> not an absolute requirement for merging, but if you can put it on your
> todo list it would be better.
> 
What's the purpose of the selftest? Is it just for Shadow Stack SSP
state transitions in various cases? e.g., L0 SSP<--->L3 SSP,
L0 SSP1<--->L0 SSP2? We now have the KVM unit-test for CET functionalities,
i.e., Shadow Stack and Indirect Branch Tracking for user-mode, I can put the
state test app into the todo list as current patchset is mainly for user-mode
protection, the supervisor-mode CET protection is the next step.

> Thanks,
> 
> Paolo