Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Stephen Fuld <sfuld@alumni.cmu.edu.invalid>
Newsgroups: comp.arch
Subject: Re: Constant Stack Canaries
Date: Mon, 31 Mar 2025 09:04:40 -0700
Organization: A noiseless patient Spider
Lines: 71
Message-ID: <vseeen$l4ig$1@dont-email.me>
References: <vsbcnl$1d4m5$1@dont-email.me> <vsc058$20pih$1@dont-email.me>
 <4cf60b5fd8b785feb07a67a823cc349d@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 31 Mar 2025 18:04:40 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c8648c9284880e9de4e5dd63c8ff0216";
	logging-data="692816"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/ei/MWtApINhG1CwyjDEaR3p3uXA7XJYw="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:TktNDdj679iO2T1gq7PUmRGq6ZQ=
In-Reply-To: <4cf60b5fd8b785feb07a67a823cc349d@www.novabbs.org>
Content-Language: en-US

On 3/30/2025 1:14 PM, MitchAlsup1 wrote:
> On Sun, 30 Mar 2025 17:47:59 +0000, BGB wrote:
> 
>> On 3/30/2025 7:16 AM, Robert Finch wrote:
>>> Just got to thinking about stack canaries. I was going to have a special
>>> purpose register holding the canary value for testing while the program
>>> was running. But I just realized today that it may not be needed. Canary
>>> values could be handled by the program loader as constants, eliminating
>>> the need for a register. Since the value is not changing while the
>>> program is running, it could easily be a constant. This may require a
>>> fixup record handled by the assembler / linker to indicate to the loader
>>> to place a canary value.
>>>
>>> Prolog code would just store an immediate to the stack. On return a TRAP
>>> instruction could check for the immediate value and trap if not present.
>>> But the process seems to require assembler / linker support.
>>>
>>
>> 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.






> 
>> Using a magic number
> 
> Remove excess words.
> 
>> Nothing fancy needed in the assemble or link stages.
> 
> They remain blissfully ignorant--at most they generate the magic
> number, possibly at random, possibly per link-module.
> 
>> In my case, canary behavior is one of:
>>    Use them in functions with arrays or similar (default);
>>    Use them everywhere (optional);
>>    Disable them entirely (also optional).
>>
>> In my case, it is only checking 16-bit magic numbers, but mostly because
>> a 16-bit constant is cheaper to load into a register in this case
>> (single 32-bit instruction, vs a larger encoding needed for larger
>> values).
>>
>> ....


-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)