linux-kernel - Re: [PATCH v2 00/21] Enable CET Virtualization

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, 23 Apr 2023 14:12:14 +0800
From:   "Yang, Weijiang" <weijiang.yang@...el.com>
To:     Peter Zijlstra <peterz@...radead.org>
CC:     <seanjc@...gle.com>, <pbonzini@...hat.com>, <john.allen@....com>,
        <kvm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <rick.p.edgecombe@...el.com>
Subject: Re: [PATCH v2 00/21] Enable CET Virtualization


On 4/22/2023 9:02 PM, Peter Zijlstra wrote:
> On Fri, Apr 21, 2023 at 09:45:54AM -0400, Yang Weijiang wrote:
>
>> Implementation:
>> --------------------------------------------------------------------------
>> Historically, the early KVM patches can support both user SHSTK and IBT,
>> and most of the early patches are carried forward with changes by this new
>> series. Then with kernel IBT feature merged in 5.18, a new patch was added
>> to support the feature for guest. The last patch is introduced to support
> Yeah, at the time I had to hack up kernel IBT guest support, because the
> platform I had to use (tgl-nuc) didn't have serial and so I had to use
> KVM :/

You did it and beat all the hurdles :-)

>> supervisor SHSTK but the feature is not enabled on Intel platform for now,
>> the main purpose of this patch is to facilitate AMD folks to enable the
>> feature.
>>
>> In summary, this new series enables CET user SHSTK/IBT and kernel IBT, but
>> doesn't fully support CET supervisor SHSTK, the enabling work is left for
>> the future.
>>
>> Supported CET sub-features:
>>
>>                    |
>>      User SHSTK    |    User IBT      (user mode)
>> --------------------------------------------------
>>      s-SHSTK (X)   |    Kernel IBT    (kernel mode)
>>                    |
>>
>> The user SHSTK/IBT relies on host side XSAVES support(XSS[bit 11]) for user
>> mode CET states. The kernel IBT doesn't have dependency on host XSAVES.
>> The supervisor SHSTK relies on host side XSAVES support(XSS[bit 12]) for
>> supervisor mode CET states.
>>
>> This version removed unnecessary checks for host CET enabling status before
>> enabling guest CET support, making guest CET support apart from that of host.
>> By doing so, it's expected to be more friendly to cloud computing scenarios.
> I've on ideas about cloud stuff, but there is fundamentally no relation
> bewteen the host making use of IBT/SHSTK and a guest doing so, so there
> should be no dependency there.

Definitely as long as there's no quirk required for the features! Also 
eliminated the

upgrade efforts for host end users in order to play with CET.

>> To run user shadow stack test and kernel IBT test in VM, you need an CET
>> capable platform, e.g., Sapphire Rapids server, and follow below steps to
>> build host/guest kernel properly:
>>
>> 1. Buld host kernel. Patch this series to kernel tree and build kernel
>> with CET capable gcc version(e.g., >=8.5.0).
> Why does the host kernel require a CET capable toolchain if the host
> kernel does not in fact need to make use of these features in order to
> provide them to the guest?

Oops, this should be a typo, guest instead of host build requires 
qualified gcc version.

Thanks for the comments!