Liste des Groupes | Revenir à c arch |
On Sun, 30 Mar 2025 17:47:59 +0000, BGB wrote:Ah, okay. I had thought the stack canaries were defined at run-time. Much easier to handle with the compiler. But, what happens when multiple instances of a program are loaded? Would it not be better to have separate stack canaries? I had thought the stack canaries would be different for each run of a program, otherwise could not some bad software discover the canary value?
On 3/30/2025 7:16 AM, Robert Finch wrote:Agreed.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.
Using a magic numberRemove 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).
>
....
Les messages affichés proviennent d'usenet.