Re: Qualcomm's Oryon boasts hardware "side-channel mitigations"

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Fri, 14 Jun 2024 15:46:02 GMT, Anton Ertl wrote:
>

... "mitigation" has a weaker sound than "fix" to me ...

>
“Mitigation” seems to be the standard term when referring to security
fixes.

When I look at
<https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html>,
e.g., for Meltdown (CVE-2017-5754), I see for some hardware "Software"
(i.e., not fixed in hardware) and for other hardware (e.g., Tiger Lake
U) "Not affected" (i.e., fixed in hardware, for CPUs like Tiger Lake U
where the ancestors were affected; for cores where the ancestors were
not affected, these were already constructed correctly, not fixed; but
if you just look at the particular hardware without considering it's
pedigree, it's just "not affected"); other entries (e.g., for Spectre
v2) have "MCU+Software" (i.e., microcode changes for supporting
software mitigations, i.e., not fixed in hardware) and
"Hardware+Software" (i.e., hardware changes for supporting software
mitigations, i.e., not fixed in hardware.  I see no mention of
"hardware mitigation" for CPUs there that are not affected.

"Mitigation" has a weak sound to be because it is used when the
security hole is not closed at all, but instead one suggests that
someone else should do something or avoid something such that the
still-existing vulnerability cannot be exploited.  E.g., in the case
of Spectre v2, to insert retpolines and/or new instructions like IBRS,
STIBP, IBPB (provided in microcode or in hardware) in the software.

Think of “fix” as a marketing term, that could suggest that you
will no further problems in future.

That's totally unlike any use of "fix" that I have seen.  Bugfixes are
provided for software all the time, and they do not promise that no
other bugs will be found in the future.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>