Re: Constant Stack Canaries

On 3/31/2025 1:07 PM, MitchAlsup1 wrote:

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.
 

OK.
I guess one could debate whether an LDM could treat the Load-LR as "Load LR" or "Load address and Branch", and/or have separate flags (Load LR vs Load PC, with Load PC meaning to branch).
Other ABIs may not have as much reason to save/restore the Global Pointer all the time. But, in my case, it is being used as the primary way of accessing globals, and each binary image has its own address range here.
PC-Rel not being used as PC-Rel doesn't allow for multiple process instances of a given loaded binary within a shared address space.
Vs, say, for PIE ELF binaries where it is needed to load a new copy for each process instance because of this (well, excluding an FDPIC style ABI, but seemingly still no one seems to have bothered adding FDPIC support in GCC or friends for RV64 based targets, ...).
Well, granted, because Linux and similar tend to load every new process into its own address space and/or use CoW.

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.
 

But... Only reason I have DIV and FDIV was because RISC-V's 'M' extension needed them, and there are generally not a whole lot of useful configurations supported by GCC that lacked 'M'.
There is FDIV, but it is painfully slow.

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" ??
 

Discontinuous register ranges:
Because pretty much no ABI's put all of the callee save registers in a contiguous range.
Granted, I guess if someone were designing an ISA and ABI clean, they could make all of the argument registers and callee save registers contiguous.
Say:
   R0..R3: Special
   R4..R15: Scratch
   R16..R31: Argument
   R32..R63: Callee Save
...
But, invariably, someone will want "compressed" instructions with a subset of the registers, and one can't just have these only having access to argument registers.

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.
 

Prolog needs a call, but epilog can just be a branch, since no need to return back into the function that is returning.
Needs to have a lower limit though, as it is not worth it to use a call/branch to save/restore 3 or 4 registers...
But, say, 20 registers, it is more worthwhile.

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...).
>