Re: Privilege Levels Below User

John Savard <quadibloc@servername.invalid> writes:

On Sun, 09 Jun 2024 16:52:45 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:
>

The proper answer to hardware bugs is not adding software limitations,
nor software mitigations (what the hardware makers suggest), but to
fix the hardware.

>
In the case of Spectre, fixing the hardware has a cost in performance.

How do you know?

Papers on so-called "invisible speculation" schemes have reported
slowdowns <10% for the more advanced schemes, with IIRC some even
reporting a speedup.

The main thing such solutions cost is area and design time.  Ok, one
can argue that the area and design time could also be spent on making
faster vulnerable hardware, and then shift the responsibility for
dealing with the vulnerabilities to software, where those mitigations
that can be generally applied cost more than a factor of 2.

So allowing the processor to run code with out-of-order execution
turned off for that code is a way to limit the performance loss to the
untrusted code.

Your trust in "trusted code" is unfounded.

And this would work well on my Concertina II architecture, where VLIW
features, such as the break bit, and extended register banks of 128
registers each, are present. Code can be generated that avoids
register hazards when run in order.

How do "register hazards" come into play?

But I have seen similar trains of thoughts several times from static
scheduling advocates.  They see Spectre as the opportunity to tout
their uncompetetive solutions by advocating solutions (like disabling
speculation) that maximize the performance loss.

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