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

[Julien Grall <julien@xxxxxxx>]

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.
 2) What happen on HW that doesn't support DIT? Are we going to mark 
them as unsupported?
>  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?
If yes, then I would argue that we should clear that bit. Otherwise...

>  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.
Cheers,

--
Julien Grall