From: user5857@newsgrouper.org.invalid
BGB posted:
> On 2/21/2026 2:15 PM, MitchAlsup wrote:
> >
> > BGB posted:
> >
> >> On 2/20/2026 5:49 PM, MitchAlsup wrote:
> >>> ----------------------------
> >>
> >> There is a non-zero risk though when one disallows uses that are
> >> theoretically allowed in the ISA, even if GCC doesn't use them.
> >
> > This is why one must decode all 32-bits of each instruction--so that
> > there is no hole in the decoder that would allow the core to do some-
> > thing not directly specified in ISA. {And one of the things that make
> > an industrial quality ISA so hard to fully specify.}}
> > ---------------------
>
> Sometimes there is a tension:
> What is theoretically allowed in the ISA;
> What is the theoretically expected behavior in some abstract model;
> What stuff is actually used by compilers;
> What features or behaviors does one want;
> ...
Whether your ISA can be attacked with Spectré and/or Meltdown;
Whether your DFAM can be attacked with RowHammer;
Whether your call/return interface can be attacked with:
{ Return Orienter Programmeing, Buffer Overflows, ...}
That is; whether you care if your system provides a decently robust
programming environment.
I happen to care. Apparently, most do not.
> Implementing RISC-V strictly as per an abstract model would limit both
> efficiency and hinder some use-cases.
One can make an argument that it is GOOD to limit attack vectors, and
provide a system that is robust in the face of attacks.
> Then it comes down to "what do compilers do" and "what unintentional
> behaviors could an ASM programmer stumble onto unintentionally".
Nïeve at best.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
