Re: Data operand dependent timing on Intel and Arm CPUs

[Mark Hack <markhack () markhack com>]

This is a concern, but if you look into the crypto implementations,
data blinding is applied to mitigate both instruction and power side
channel attacks

Regards

Mark Hack



On Thu, 2023-01-26 at 22:09 +0000, Eric Biggers wrote:
> On Wed, Jan 25, 2023 at 10:44:45PM +0100, Solar Designer wrote:
> > Hi Eric,
> >
> > Thank you for bringing this up in here.
> >
> > There was also a brief Twitter thread on it in August 2022, started
> > by
> > Adam Langley:
> >
> > https://twitter.com/agl__/status/1561374334714671104
> >
> > In it Adam Langley, wrote:
> > > It appears that Intel doesn't guarantee constant-time execution
> > > of _any_
> > > instructions on Ice Lake or later unless a configuration bit is
> > > set:
> > > https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/data-operand-independent-timing-isa-guidance.html
> > >
> > > Ice Lake was released in 2019 but this information is only a few
> > > months
> > > old. So hopefully multiplication etc actually is always constant-
> > > time on
> > > existing chips and this is just preparing for the future?
> > >
> > > I guess the steady state is that every OS sets this DOITM bit all
> > > the
> > > time, but Intel get to publish benchmarks based on variable-time
> > > instructions and claim that they're using the default
> > > configuration?
> >
> > My reply was:
> > > Reading between the lines, I think this is a vulnerability and
> > > mitigations disclosure for 6th to 12th gen (fixed in 13th?),
> > > disguised
> > > as a feature. They discovered that "data values may delay
> > > instruction
> > > retirement by, at most, one cycle" for vector multiplication and
> > > bit
> > > count.
> >
> > On Wed, Jan 25, 2023 at 11:34:43AM -0800, Eric Biggers wrote:
> > > I'd like to draw people's attention to the fact that on recent
> > > Intel and Arm
> > > CPUs, by default the execution time of instructions may depend on
> > > the data
> > > values operated on.  This even includes instructions like
> > > additions, XORs, and
> > > AES instructions, that are traditionally assumed to be constant-
> > > time with
> > > respect to the data values operated on.
> >
> > FWIW, I'm not aware of any indication that e.g. "additions, XORs,
> > and
> > AES instructions" have data-dependent timing on CPUs released so
> > far.
>
> Sure.  To be clear, I don't have specific knowledge of how particular
> instructions behave on particular CPUs.  Research into the real-world 
> behavior
> is absolutely needed.  I'm just going off what the Intel
> documentation is saying
> is possible / allowed now.  Additions, XORs, and AES-NI instructions
> all show in
> the following list of instructions:
> https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/resources/data-operand-independent-timing-instructions.html
>
> Now, that list is titled "Data Operand Independent Timing
> Instructions".  That
> sounds good; it means they have data operand independent timing,
> right?
>
> Actually, not necessarily.  If you read the documentation fully,
> specifically
> the "Data Operand Independent Timing Mode (DOITM)" section of
> https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/data-operand-independent-timing-isa-guidance.html,
> it says that the instructions in that list are only guaranteed to
> have data
> operand independent timing ***if the DOITM flag is enabled***.
>
> Also, Intel writes:
>
>       "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."
>
> So, Intel is saying that on older CPUs, the instructions in that list
> are
> guaranteed to always have data operand independent timing.  But on
> newer CPUs it
> is ***explicitly not guaranteed by default***.
>
> I'd be happy if people looked into this and found that in the real
> world, data
> operand independent timing by default is actually still the status
> quo.
>
> Of course, that would mean that while enabling DOITM would not
> currently be
> important, the overhead of enabling it would also be very small.
>
> Conversely, if DOITM gets more expensive in the future, surely that
> could only
> be the result of it becoming much more important to enable anyway...
>
> - Eric