[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 00/10] Preemption in hypervisor (ARM only)
- To: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Julien Grall <julien.grall.oss@xxxxxxxxx>
- From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Date: Thu, 25 Feb 2021 00:39:56 +0000
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nPDUblydehS6l+/YSHhxieL6FYDcnWbzljL9LshT6rM=; b=be8hisUrDXyr4NAPGNgT0E0qGL/okhih+EjHzUVHHgNfSWgriZUgAUg4diABIDxFc/ll5E4er1gDGtT8Ia1GmUvfz46WQOdf2VqyD6HJ7swqkSlGL6JHlNgEMcyvxwdOsZIvhdtFz9U+3O6U9KixnNKxSEIFBWlea2uVKsj1S7Xujxk6HSuMQ5ySCMQMge9Xi1rYY1eucLndPpse8qd0iNBlXUTW0iT9BcXIt/vy19kXxtWMzCermP1o6m33uzNoGaLS1gke9p0Z8Nkv0eoc3Tew+WV4jDqsz53r2t8J5szSh6lWJPEznV2naCXNba7ktazfpngl8NWWUhxjMCyy/A==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MG6ByNtmZX3pSUx2FjPq4HvQkvUUHblAzZ6guIX0Au8lDrIojoRo5fNUFW+Zl1g11h8ZqlMCcWV5Udv32TFS3hkPmSj1rZa6uqW7cn91i2TIdFdcvGaMbMTxPZp+IKoS2miBYeOMgN11vbJEF9Obv9NjDENOLuwDTF4Wo8ScZhO+HBp+wtLzGEhyi/bHZnMcvT6Y3Ay3JyTe14xIepU34Nu9UVJonSi4glc1z+OsgeNgpyJeJ4bipdBdcFW3nHFBf5JP8/hXQkgjDpT5JS+/hfatcLeWBKyvTCgBjafOOgAXo5mBH5cGy4uKtnWYgBzw41JItEL23docka5QCWRE3w==
- Authentication-results: esa2.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Dario Faggioli <dfaggioli@xxxxxxxx>, Meng Xu <mengxu@xxxxxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
- Delivery-date: Thu, 25 Feb 2021 00:40:45 +0000
- Ironport-sdr: cBOIVlwWvxE1iZG2TDbbzx0k/WL5tWuLjl8Lz1Cr0hugJ1/CIaEHPh5/KxG1E+1fcZGfJZJmPF gamstplSS/e1rMGDEPFBU/ts/zttX+EvV71vyOPCZny4mJdnnrJ7ZLS7tUU923fjfv/yKV6Dpy BZP0NmOqMRbXH/hhSZFFK/s21d/GeK4Um6L3QmKCh3SRdsmxDYHITkN2e8H9tjn5x5saJGxf/v L89K0HX5+cMPA+a/xUhLA5uxefxyuCTb8J7JxqtTdxUN+jFbgzvfIf/LODzSa1owK0e/jazE4q 2yk=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 24/02/2021 23:58, Volodymyr Babchuk wrote:
> And I am not mentioning x86 support there...
x86 uses per-pCPU stacks, not per-vCPU stacks.
Transcribing from an old thread which happened in private as part of an
XSA discussion, concerning the implications of trying to change this.
~Andrew
-----8<-----
Here is a partial list off the top of my head of the practical problems
you're going to have to solve.
Introduction of new SpectreRSB vulnerable gadgets. I'm really close to
being able to drop RSB stuffing and recover some performance in Xen.
CPL0 entrypoints need updating across schedule. SYSCALL entry would
need to become a stub per vcpu, rather than the current stub per pcpu.
This requires reintroducing a writeable mapping to the TSS (doable) and
a shadow stack switch of active stacks (This corner case is so broken it
looks to be a blocker for CET-SS support in Linux, and is resulting in
some conversation about tweaking Shstk's in future processors).
All per-cpu variables stop working. You'd need to rewrite Xen to use
%gs for TLS which will have churn in the PV logic, and introduce the x86
architectural corner cases of running with an invalid %gs. Xen has been
saved from a large number of privilege escalation vulnerabilities in
common with Linux and Windows by the fact that we don't use %gs, so
anyone trying to do this is going to have to come up with some concrete
way of proving that the corner cases are covered.
|
