Re: Another security vulnerability

Lawrence D'Oliveiro wrote:

On Wed, 27 Mar 2024 09:22:12 -0700, Stephen Fuld wrote:

On 3/25/2024 5:27 PM, Lawrence D'Oliveiro wrote:
>

On Mon, 25 Mar 2024 22:17:55 +0000, MitchAlsup1 wrote:
 

Lawrence D'Oliveiro wrote:
>

The basic problem is that building all this complex, bug-prone
functionality into monolithic, nonupgradeable hardware is not really
a good idea.

>
Would you like to inform us of how it can be done otherwise ?

 Upgradeable firmware/software, of course.

 But microcode is generally slower than dedicated hardware, and most
people seem to be unwilling to give up performance all the time to gain
an advantage in a situation that occurs infrequently and mostly never.

S.E.L 32/65, 32/67, 32/87 were all microcoded. 95% of the instructions*
ran down the pipeline without using the microcode (which was only there
to pick up the pieces after HW logic sequencers got tooo complicated.
(*) closer to 97% of the dynamic instruction stream.
Microcode IS generally slower, but not always. PDP-11 or VAX microcode
is too much, IBM, S.E.L. is not too much.

Bruce Schneier has a saying: “attacks never get worse, they can only get better”.

Which is why to have to design for attackers (to be thwarted}.
Observing the last 4-odd years, it appears to me that CPU designers will
not be in a position to "give a rat's ass" until there is performance
competitive, cost competitive, alternatives. Given Apple, AMD, ARM, and
Intel not giving a rat's ass, it's going to have to come from somewhere
else.