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

[Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx>]

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

On Thu, Sep 15, 2022 at 01:56:06PM +0100, Julien Grall wrote:
> Hi Demi,
> 
> On 15/09/2022 12:24, Demi Marie Obenour wrote:
> > 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 <demi@xxxxxxxxxxxxxxxxxxxxxx>
> > > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> > 
> > 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.
> 
> 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-----