Guard byte

<h2 id="principle">Principle</h2>
<p>When a <a href="/facts/Computer_program/e38jH9N9">program</a> is <a href="/facts/Compiler/WNfCDFJe">compiled</a> for <a href="/facts/Debugging/QtdpPJT0">debugging</a>, all <a href="/facts/Memory_(computers)/hQKVQ51J">memory</a> allocations are prefixed and postfixed by guard bytes. Special memory allocation <a href="/facts/Subroutine/9vFJrg0A">routines</a> may then perform additional tasks to determine unwanted read and write attempts outside the allocated memory. These extra bytes help to detect that the program is writing into (or even reading from) inappropriate memory areas, potentially causing <a href="/facts/Buffer_overflow/uMFduL4B">buffer overflows</a>. In case of accessing these bytes by the program's algorithm, the programmer is warned with information assisting them to locate the problem.
</p><p>Checking for the inappropriate access to the guard bytes may be done in two ways:
</p>
<ul><li>by setting a <i>memory <a href="/facts/Breakpoint/LgtYUIlq">breakpoint</a></i> on a condition of write and/or read to those bytes, or</li>
<li>by pre-initializing the guard bytes with specific values and checking the values upon deallocation.</li></ul>
<p>The first way is possible only with a <a href="/facts/Debugger/mCe6UsWj">debugger</a> that handles such breakpoints, but significantly increases the chance of locating the problem. The second way does not require any debuggers or special <a href="/facts/Integrated_development_environment/jbEINSQf">environments</a> and can be done even on other computers, but the programmer is alerted about the overflow only upon the deallocation, which is sometimes quite late.
</p><p>Because guard bytes require additional code to be executed and additional memory to be allocated, they are used only when the program is compiled for debugging. When compiled as a <i>release</i>, guard bytes are not used at all, neither the routines working with them.
</p>
<h2 id="example">Example</h2>
<p>A programmer wants to allocate a <a href="/facts/Buffer_(computer_science)/tVy4j2Dc">buffer</a> of 100 bytes of memory while debugging. The system memory allocating <a href="/facts/Subroutine/9vFJrg0A">routine</a> will allocate 108 bytes instead, adding 4 leading and 4 trailing guard bytes, and <a href="/facts/Return_statement/lK7c71aa">return</a> a <a href="/facts/Data_pointer/fPoNzy9b">pointer</a> shifted by the 4 leading guard bytes to the right, <i>hiding</i> them from the programmer. The programmer should then work with the received pointer without the knowledge of the presence of the guard bytes.
</p><p>If the programmer's algorithm writes right outside the assigned space, it will overwrite the guard bytes. Later, upon deallocation, the deallocating routine will check, whether the guard bytes are modified and reports an error if appropriate.
</p>
<h2 id="problems">Problems</h2>
<p>Memory allocation routines fill guard bytes with values that are not supposed to be used by the programmer's algorithms. This is, however, not predictable. When the algorithm uses those values and overwrites the guard bytes with them (only the last write before deallocation is relevant), the overflow can not be detected, because the bytes have not actually changed. Instead, the memory breakpoint option can be used, set on a condition of access to those bytes in a debugger.
</p>
<h2 id="see-also">See also</h2>
<ul><li><a href="/facts/Buffer_overflow_protection/eNFYvHVk">Buffer overflow protection</a></li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1"><p>"Security Technologies: Stack Smashing Protection (StackGuard)". www.redhat.com. Retrieved 2024-09-19. <a href="https://www.redhat.com/en/blog/security-technologies-stack-smashing-protection-stackguard" target="_blank">https://www.redhat.com/en/blog/security-technologies-stack-smashing-protection-stackguard</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li>
</ol>

Guard byte open-in-new

Guard byte