On 14.09.2023 11:18, Julien Grall wrote: > On 14/09/2023 10:11, Jan Beulich wrote: >> On 14.09.2023 11:04, Julien Grall wrote: >>> On 14/09/2023 07:32, Jan Beulich wrote: >>>> On 13.09.2023 19:56, Julien Grall wrote: >>>>> If not, I think we should taint Xen and/or print a message if the admin >>>>> requested to use DIT. This would make clear that the admin is trying to >>>>> do something that doesn't work. >>>> >>>> Tainting Xen on all hardware not exposing the bit would seem entirely >>>> unreasonable to me. If we learned of specific cases where the vendor >>>> promises are broken, we could taint there, sure. I guess that would be >>>> individual XSAs / CVEs then for each instance. >>> >>> ... we need to somehow let the user know that the HW it is running on >>> may not honor DIT. Tainting might be a bit too harsh, but I think >>> printing a >>> message with warning_add() is necessary. >> >> But Intel's claim is that with the bit unavailable hardware behaves as >> if DIT was in effect. > > I am confused. Above, you suggested it cannot be guaranteed. So I > interpreted we don't know what's happening on any processor.
Right. We can trust vendors, or not. > So where > you referring to... > > > Therefore you're still suggesting to emit a >> warning on most of Intel's hardware and on all non-Intel one. > > ... non-Intel HW? > >> That's >> going too far, imo. > > We could restrict the warning to non-Intel platform. That still goes too far imo. I'm not convinced we should cover for vendor uncertainty here. We can't make a system any safer than its hardware is, in this regard. We simply have no (or not enough) influence on the internal workings of their pipelines. What I have done is add a sentence to the command line option's documentation: "Note that enabling this option cannot guarantee anything beyond what underlying hardware guarantees (with, where available and known to Xen, respective tweaks applied)." Plus I've further qualified the option: ### dit (x86/Intel) Jan
