On Tue, Jan 31, 2023 at 02:48:05PM -0800, Dave Hansen wrote: > We've been talking about this inside Intel. Suffice to say that DOITM > was not designed to be turned on all the time. If software turns it on > all the time, it won't accomplish what it was designed to do. Why wouldn't it accomplish what it is designed to do? Does it not actually work? > > The _most_ likely thing that's going to happen is that DOITM gets > redefined to be much more limited in scope. The current DOITM > architecture is very broad, but the implementations have much more > limited effects. This means that the architecture can probably be > constrained and still match the hardware that's out there today. That's > pure speculation (ha!) on my part. > > I think we should hold off on merging any DOITM patches until the dust > settles. As far as I know, there is no pressing practical reason to > apply something urgently. > > Any objections? Does this mean that Intel will be restoring the data operand independent timing guarantee of some instructions that have had it removed? If so, which instructions will still be left? Also, given that the DOITM flag can only be set and cleared by the kernel, and assuming that Linux won't support DOITM in any way yet (as you're recommending), what should the developers of userspace cryptographic libraries do? Does Intel have a list of which instructions *already* have started having data operand dependent timing on released CPUs, so that the existing security impact can be assessed and so that developers can avoid using those instructions? - Eric
