Re: Constant Stack Canaries

On Mon, 31 Mar 2025 17:17:38 +0000, BGB wrote:

On 3/31/2025 11:04 AM, Stephen Fuld wrote:

On 3/30/2025 1:14 PM, MitchAlsup1 wrote:

On Sun, 30 Mar 2025 17:47:59 +0000, BGB wrote:
-------------

>
They are mostly just a normal compiler feature IME:
   Prolog stores the value;
   Epilog loads it and verifies that the value is intact.

>
Agreed.

>
I'm glad you, Mitch, chimed in here.  When I saw this, it occurred to me
that this could be done automatically by the hardware (optionally, based
on a bit in a control register).   The CALL instruction would store
magic value, and the RET instruction would test it.  If there was not a
match, an exception would be generated.  The value itself could be
something like the clock value when the program was initiated, thus
guaranteeing uniqueness.
>
The advantage over the software approach, of course, is the elimination
of several instructions in each prolog/epilog, reducing footprint, and
perhaps even time as it might be possible to overlap some of the
processing with the other things these instructions do.  The downside is
more hardware and perhaps extra overhead.
>
Does this make sense?  What have I missed.
>

>
This would seem to imply an ISA where CALL/RET push onto the stack or
similar, rather than the (more common for RISC's) strategy of copying PC
into a link register...
>
>
Another option being if it could be a feature of a Load/Store Multiple.
>
Say, LDM/STM:
   6b Hi (Upper bound of register to save)
   6b Lo (Lower bound of registers to save)
   1b LR (Flag to save Link Register)
   1b GP (Flag to save Global Pointer)
   1b SK (Flag to generate a canary)

ENTER and EXIT have 2 of those flags--but also note use of SP and CSP
are implicit.

Likely (STM):
   Pushes LR first (if bit set);
   Pushes GP second (if bit set);
   Pushes registers in range (if Hi>=Lo);
   Pushes stack canary (if bit set).

EXIT uses its 3rd flag used when doing longjump() and THROW()
so as to pop the call-stack but not actually RET from the stack
walker.

LDM would check the canary first and fault if it doesn't see the
expected value.
>
Downside, granted, is needing the relative complexity of an LDM/STM
style instruction.

Not conceptually any harder than DIV or FDIV and nobody complains
about doing multi-cycle math.

Other ISAs use a flag bit for each register, but this is less viable
with an ISA with a larger number of registers, well, unless one uses a
64 or 96 bit LDM/STM encoding (possible). Merit though would be not
needing multiple LDM's / STM's to deal with a discontinuous register
range.

To quote Trevor Smith:: "Why would anyone want to do that" ??

Well, also excluding the possibility where the LDM/STM is essentially
just a function call (say, if beyond certain number of registers are to
be saved/restored, the compiler generates a call to a save/restore
sequence, which is also generates as-needed). Granted, this is basically
the strategy used by BGBCC. If multiple functions happen to save/restore
the same combination of registers, they get to reuse the prior
function's save/restore sequence (generally folded off to before the
function in question).

Calling a subroutine to perform epilogues is adding to the number of
branches a program executes. Having an instruction like EXIT means
when you know you need to exit, you EXIT you don't branch to the exit
point. Saving instructions.

Granted, the folding strategy can still do canary values, but doing so
in the reused portions would limit the range of unique canary values
(well, unless the canary magic is XOR'ed with SP or something...).
>