[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] x86/CPUID: surface suitable value in EBX of XSTATE subleaf 1
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- Date: Wed, 24 Aug 2022 12:19:10 +0000
- Accept-language: en-GB, en-US
- 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IGcd5ZcjbmRQhx5gbt2DI9DYDAOyLUw4qv6d3xNMfm8=; b=U1JxJ7c+duAGIHMS2e5teQ2dZQMmdCyOXpAyYqHZ7STIDEGTN5rq6de9XCQB8tWJw6l1a/d8Qp2+DgqBwmYFLbX+ErjpVGHVlxxynVuZuYD01lG0h/TjQG/7dSBwFJiK1RGCBImftr6ZMG00XDyfBscelIPJ5hfBjLRc5IYBb0apFFQmJHcSiDaHGIk6zf9DRHmbrKmIzskZhi5jo9i0eex+YIdRH2cDABeid1bCv7vdMPw3j69qX02Xowbig7hGqBSocOsew5iA4zBUsG8tLkSUlebdOgIDeW1NCowGAn+Wpf5OSeMh0lgcC+jDYRCnY4HeuxWr8QfRJOOFX0+F4g==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fgrWfAO5JlBcc9yHNuxbnrnbOblvGxP158DWaX56gic52nCnYLDLKC4cHgf4yFv9arGt1dyXgeeOaFK0a4sXCDK64nHRlRrAzcp4FzE+SgZy5tc9kp5t63lvdHIV/gRgSLFcWdPtRtjQjwviRDqzShHc2z0o3r1a3JaqO3e/sFWp6YwDm+FnVbIXmEOppJQVnoL7CD6+5I1CiWGvQwiIHKnC1SdgNXLnpeGdoyyWvQbBwXNaYndn0ukrPemfpelqNhk5msJ9/Q9I2gNeEvTZ3HXltGFbWbM1UsYQu7baTxSnfBUUlJWJlnv1FNpwtehWNbcyA4V8rTYxBphul16UEw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Wed, 24 Aug 2022 12:19:23 +0000
- Ironport-data: A9a23:w+3W16PXc58xIyzvrR1wlsFynXyQoLVcMsEvi/4bfWQNrUor0zcPz DQWC2qDMvvZazHyfNB1aY2+80NQvpPWmoc2Tgto+SlhQUwRpJueD7x1DKtR0wB+jCHnZBg6h ynLQoCYdKjYdleF+lH3dOCJQUBUjcmgXqD7BPPPJhd/TAplTDZJoR94kqsyj5UAbeKRWmthg vuv5ZyEULOZ82QsaDhMu/jf8EoHUMna41v0gHRvPZing3eG/5UlJMp3Db28KXL+Xr5VEoaSL woU5Ojklo9x105F5uKNyt4XQGVTKlLhFVHmZk5tc7qjmnB/Shkaic7XAha+hXB/0F1ll/gpo DlEWAfZpQ0BZsUgk8xFO/VU/r0X0QSrN9YrLFDm2fF/wXEqfFPn6MVOMhoHILQ64/x+Wk9C1 dc+BGACO0Xra+KemNpXS8FKr+F7dozBGtpavXttizbEEfwhXJbPBb3Q4sNV1ysxgcYIGuvCY 80eanxkaxGojx9nYw9LTs5h2rrxwCWvG9FbgAv9Sa4fym7f1gFulpPqN8LYYIeiTsRJhEeI4 GnB+gwVBzlFZITGlWXUqxpAgMfDuXK4eKQ5EYGi8/06x2yU2UIMMhAJAA7TTf6RzxTWt8hkA 04e9zcqrKMy3Fe2VdS7VBq9yFabujYMVtwWFPc1gCmIw7DR6hyUBUAFSCBAc90ssMIqRT0s2 USNltmvDjtq2JWJRnaN3rOVqy6uIy8TLH9EaSJsZRsI5ZzvrZ8+ijrLT81/C+ilg9vtAzbyz juW6i8kiN0uYdUj0qy6+RXNhWuqr52REQotvF2LDiSi8x9zY5Oja8qw81/H4P1cLYGfCF6co HwDnMvY5+cLZX2QqBGwrCw2NOnBz5643Pf02zaDw7FJG+yRxkOe
- Ironport-hdrordr: A9a23:L+3vKqn0aGQnSR7xDRKvEueKTa/pDfOPimdD5ihNYBxZY6Wkfp +V8cjzhCWftN9OYhodcIi7SdK9qXO1z+8X3WGIVY3SETUOy1HYVr2KirGSjwEIeheOvNK1sJ 0NT0EQMqyWMbEXt6fHCUyDYq4dKbq8ge+VbIXlvhFQpGhRAskOgTuRSDzra3GeLzM2Z6bRYa Dsgvav0ADQHEj/AP7aOlA1G8z44/HbnpPvZhALQzQ97hOVsD+u4LnmVzCFwxY3SVp0sPYf2F mAtza8yrSosvm9xBOZ/XTU9Y5qlNzozcYGLNCQi/ISNi7nhm+TFcRcsvy5zXMISdOUmRMXee r30lMd1gNImjTsl1SO0FnQMs/boXATAjHZuAalaDDY0LHErXoBerZ8bMRiA1XkAgMbza9BOO gg5RPni7NHSRzHhyjz/N7OSlVjkVe1u2MrlaoJg2VYSpZ2Us4ZkWUzxjIjLH47JlON1Kk3VO 11SM3M7vdfdl2XK3jfo2l02dSpGnA+BA2PTEQOstGcl2E+pgEz82IIgMgE2nsQ/pM0TJdJo+ zCL6RzjblLCssbd7h0CusNSda+TmbNXRXPOmSPJkmPLtBOB1vd75rspLkl7uCjf5IFiJM0hZ TaSVtd8XU/fkr/YPf+qKGjMiq9NVlVcQ6duv22vaIJy4EUbICbQhGrWRQpj9aqpekZD4nSR+ uzUagmccPeEQ==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHYtrt8/1v0WOY/4kiCtfQ8qrAcS628L8cAgAAH3wCAABa0AIABQecAgABptQA=
- Thread-topic: [PATCH] x86/CPUID: surface suitable value in EBX of XSTATE subleaf 1
On 24/08/2022 07:00, Jan Beulich wrote:
> On 23.08.2022 12:48, Andrew Cooper wrote:
>> On 23/08/2022 10:27, Jan Beulich wrote:
>>> On 23.08.2022 10:59, Andrew Cooper wrote:
>>>> But this is going to further complicate my several-year-old series
>>>> trying to get Xen's XSTATE handling into a position where we can start
>>>> to offer supervisor states.
>>> Where do you see further complication? The necessary fiddling with XSS
>>> here would of course be dependent upon p->xstate.xsaves alone (or,
>>> maybe better, on the set of enabled features in XSS being non-empty),
>>> but that's simply another (inner) if().
>>>
>>> As an aside, I actually wonder what use the supplied size is to user
>>> mode code when any XSS-controlled feature is enabled: They'd allocate
>>> a needlessly large block of memory, as they would only be able to use
>>> XSAVEC.
>> This field is an already known kernel=>user infoleak. There are threads
>> about it on LKML.
>>
>> But it does highlight another problem. This change does not fix Linux
>> on AMD Zen3 hardware, where the kernel will find the CPUID value larger
>> than it can calculate the size to be, because Xen's use of CET-SS will
>> show up in the CPUID value.
> Why would that be? We don't even have CET related defines for XCR0, so
> we don't enable the states in XSS. And I don't see why we would. Even
> for other XSTATE-managed but not XSTATE-enabled features we could
> clear the respective bits around the CPUID invocation (just like we
> may need to set some in XSS). We'd be in trouble only for any XSTATE-
> enabled feature that we make use of ourselves.
It's not Xen's CPUID invocation which is relevant. It's the guest
kernels, which goes straight to hardware because AMD still doesn't have
CPUID faulting.
And yes, right now none of Xen's CET state shows up in XSTATE, but that
needs to change in order to support CET in HVM guests if we don't want
an enormous extra overhead in the general context switch path.
~Andrew
|
