From: cr88192@gmail.com
On 2/21/2026 4:56 PM, MitchAlsup wrote:
>
> 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.
>
There is a way at least, as noted, to optionally provide some additional
protection against buffer overflows (in a compiler that does not use
stack canaries, eg, GCC).
But, as-noted, it disallows AUIPC+JALR to use X1 in this way.
Even if compiler output does generally use X5 for this case.
>> 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.
>
This was a partial motivation for deviating from the abstract model.
Deviating from the abstract model in some cases allows closing down
attack vectors.
>> Then it comes down to "what do compilers do" and "what unintentional
>> behaviors could an ASM programmer stumble onto unintentionally".
>
> Nïeve at best.
>
Possibly, but there are some things a case can be made for disallowing:
Using X1 for things other than as a Link Register;
Disallowing JAL and JALR with Rd other than X0 or X1;
Disallowing most instructions, other than a few special cases, from
having X0 or X1 as a destination.
RISC-V has a lot of "Hint" instructions, but a case can be made for
making many of them illegal (where trying to use them will result in an
exception; rather than simply ignoring them).
In some other cases, it may be justified to disallow (and generate an
exception for) things which can be expressed in the ISA, technically,
but don't actually make sense for a program to make use of (some amount
of edge cases that result in NOPs, or sometimes non-NOP behaviors which
don't actually make sense); but are more likely to appear in undesirable
cases (such as the CPU executing random garbage as instructions).
...
Say, for example, the normal/canonical RISC-V NOP can't be expressed
without 0x00 (NUL) bytes, whereas many other HINT type instructions can
be encoded without NUL bytes.
If someone can't as easily compose a NUL-byte-free NOP-slide, it makes
it harder to inject shell code via ASCII strings (as does hindering the
ability to tamper with return addresses), avoiding casual use of RWX
memory, etc.
The JAL/JALR Rd=X0|X1 only case, is one of those cases where one can
argue a use-case exists, but is so rarely used as to make its native
existence in hardware (or in an ISA design) difficult to justify. In
effect, supporting it in HW adds non-zero cost, programs don't actually
use it, and it burns 4 bits of encoding space you aren't really getting
back (and they could have used it for something more useful, say, making
JAL has a 16MB range or something).
While one can't change the encoding now, they can essentially just turn
the generic case into a trap and call it done.
...
Though. yes, even if one nails all this down, there are still often
other (nor-memory) attack vectors (such as attacking program logic).
Saw something not too long ago where there was an RCE exploit for some
random system (which operated via an HTTP servers and HTTP requests; I
think for "enterprise supply-chain stuff" or something), where the
exploit was basically the ability to execute arbitrary shell commands
via expressing them as an HTTP request (with said server effectively
running as "setuid root" or similar).
Or, basically, something so insecure that someone could (in theory) hack
it by typing specific URLs into a web browser or something (or maybe
using "wget" via a bash script).
Like, something like:
http : //someaddress/cgi-bin/system.cgi?cmd=sshd%20...
(Say, spawn an SSH server so they can stop using HTTP requests).
Leaving people to just ROFLOL about how bad it was...
And, how did the original product operate?... Mostly by sending
unsecured shell commands over HTTP.
So, alas...
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
