Re: [PATCH for-4.17?] x86: support data operand independent timing mode

[Demi Marie Obenour]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Thu, Sep 15, 2022 at 12:04:55PM +0200, Jan Beulich wrote:
> [1] specifies a long list of instructions which are intended to exhibit
> timing behavior independent of the data they operate on. On certain
> hardware this independence is optional, controlled by a bit in a new
> MSR. Provide a command line option to control the mode Xen and its
> guests are to operate in, with a build time control over the default.
> Longer term we may want to allow guests to control this.
>
> Since Arm64 supposedly also has such a control, put command line option
> and Kconfig control in common files.
>
> [1] https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/data-operand-independent-timing-isa-guidance.html
>
> Requested-by: Demi Marie Obenour <de...@invisiblethingslab.com>
> Signed-off-by: Jan Beulich <jbeu...@suse.com>

Thanks for the patch, Jan!

> This may be viewed as a new feature, and hence be too late for 4.17. It
> may, however, also be viewed as security relevant, which is why I'd like
> to propose to at least consider it.

I consider it security relevant indeed, which is why I was so insistent
on it. Whether it is worth a full XSA is up to the Xen Security Team.
If it could be backported to stable releases, that would be great.

Marek, Simon, would you consider backporting this to R4.1?

> Slightly RFC, in particular for whether the Kconfig option should
> default to Y or N.

I think it should default to Y as long as guests do not have the ability
to control this. Otherwise any cryptographic code in the guests thinks
it is constant time when it may not be. Once guests have the ability to
control this I would be open to reconsidering this.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmMjC4MACgkQsoi1X/+c
IsELUg//fTRCauj/woVL8a3NpcB/2T2/gM06Lhg/eT7DsW4aJEIinB+jZ1mQ4oUb
MWEe3Ljwo0bxhbWbbQt2Xqp0pRM1MsDT7D0Boe0qEbpFYCgs8NrRvNE+MrtXG24x
B+2E/KZBIesjLV26S3uWTItHfUiFbqo5xzJURCDNHZqZiDnvCs4adiCMNDfroXyL
4UnP1slglrL/x/WqU9VKsWOOJAHTId2cBFd5FDlCQ7UX/GQISUIk7NZqCvutbtny
nJpSlbYoUcuQ3IfB4S7zDE4sN2YatCDqojZsAYuwRCRCRgM4nmZJUvK5KwzR1k6Z
0DfvZ0R4h5gdSrylqABzteEwLbob2icXxY89QHhssh/737R0HE5sRK2HKOPRZgUz
bmdlismQMqAuzUceAFreIGoPsIQUongF2xZJIY6AtGLudvaB8GZVyeJCgvH/eYyA
N05zybw3brLDgTjLN+HXTtsH4X7t4/ktCbGCLZWUytu5h4tr/wg/IXhd84uCu88n
3oLHLuqtpJUNItDYSmLSNQ7KO3Py4pbGjV7ienUl4fGpLS9MKG6raCTj12xO5nq8
5C/vMuzCRiJF3lEvHOrkVjH7vANk/8pfnqoHoMHs4lM2QnlskdOsjCPa17ZZWHs0
knT9OrN4hL7GgA2aU33rfhvgtDq6p7n5Xg2+YbNAbj7lSydjSho=
=dfry
-----END PGP SIGNATURE-----

[Demi Marie Obenour]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Thu, Sep 15, 2022 at 01:56:06PM +0100, Julien Grall wrote:
> Hi Demi,

> This raises two questions:
> 1) What is the performance impact to turn this on by default? I am looking
> for actual numbers.

I do not have access to such hardware and so cannot provide such
numbers. I was hoping that someone else would be able to do the needed
benchmarking.

> 2) What happen on HW that doesn't support DIT? Are we going to mark them as
> unsupported?

The relevant text in Intel’s documentation is:

> For Intel® Core™ family processors based on microarchitectures before
> Ice Lake and Intel Atom® family processors based on microarchitectures
> before Gracemont that do not enumerate IA32_UARCH_MISC_CTL, developers
> may assume that the instructions listed here operate as if DOITM is
> enabled.
>
> Intel Core family processors based on Ice Lake and later, such as
> Tiger Lake, Lakefield, and Rocket Lake will enumerate DOITM. Intel
> Atom processors based on Gracemont and later will also enumerate
> DOITM. Refer to the Enumeration and Architectural MSRs section for
> more information.

In other words, no action is needed (or possible) on CPUs that do not
enumerate DOITM. CPUs that do enumerate DOITM require it to be
explicitly enabled by for cryptographic code to be secure. This was a
poor design decision on Intel’s part, which might be why it appears that
Linux will treat DOITM as a CPU bug.

> > Otherwise any cryptographic code in the guests thinks
> > it is constant time when it may not be.
>

> Why would a guest think that? Are we telling the guest DIT is supported but
> doesn't honour it?

Xen is telling guests that DOITM is not required for constant-time
operation of cryptographic code, even though the hardware actually
requires it. Furthermore, Xen does not allow guests to set DOITM.

> If yes, then I would argue that we should clear that bit. Otherwise...

Xen actually needs to *set* that bit, not clear it.

> > Once guests have the ability to
> > control this I would be open to reconsidering this.
>

> ... this will introduce a problem once we expose it to the guest because we
> cannot change the global default as some user my start to rely on it on the
> default.

I would be fine with requiring the toolstack to opt-out from the safe
default.

- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmMjNDYACgkQsoi1X/+c
IsEi+RAAskGqEC1ParSsfyWS7fw9mhKzH+pS+IsKE5tjCu1l6Ctub17qqysC3Oej
yzqMPuK+YwwEW5X3SNlnd6Qs5C/2XIdkr8cwB8PitjMabS1dvJu01qIRbIyMDM2i
ii9qtuTLCDUAz5rrLW+qr0TE9vBcfteOKzkcWkmQQpWjermZHy+lHooXNmwjS9oc
J+nGbUWhNy1uNvFA+sUjEcEucAlSyM7UWkL/c9FzfWV2UwPWppdGpyz7jrRdZT+H
brb3FwRd1hoS4t94Xv9ynzZ9K7KeEZ5pF8rKOoKh0cfZ9Ydcuh0wr9dtD6aWTS3r
I2rNQig6AqurCF6AVUIlwf6TYcI71BRNDB3SQNAh7h5yxjy1S0srE0RLIZXFiboz
0RAyq76NFWS9qN2BG11PvfaG665EL14+7I+xaJxeSwPOZlUmbhTznYN7thFlx5MC
AxSwthokvIThiy1tpu3XdiU1zFWb5Spd4vwkSv/bo2fCPySECJ59tGsDtNvreJbf
z7A1CB968bTdPJAsYgY2OkkO+zFm3vR+fmrSia5b5cHoY80Mb0FmxKrPKxcOsyHJ
PJGoWMDxRxi0RTYi5nrI3qGWJSl9GpryQPX5jaB01mLcXHo/mmQB1PiFda+PioPa
T/bwpiYCc06EyeuJBMfu0Gv9NYnAuDC7qBtJfjKzm+OofrfWzQI=
=mpE9
-----END PGP SIGNATURE-----