GNAT can guard against unexpected execution flows, such as branching into the middle of subprograms, as in Return Oriented Programming exploits.
In units compiled with
subprograms are instrumented so that, every time they are called,
basic blocks take note as control flows through them, and, before
returning, subprograms verify that the taken notes are consistent with
the control-flow graph.
Functions with too many basic blocks, or with multiple return points, call a run-time function to perform the verification. Other functions perform the verification inline before returning.
Optimizing the inlined verification can be quite time consuming, so
the default upper limit for the inline mode is set at 16 blocks.
--param hardcfr-max-inline-blocks= can
Even though typically sparse control-flow graphs exhibit run-time
verification time nearly proportional to the block count of a
subprogram, it may become very significant for generated subprograms
with thousands of blocks. Command-line option
--param hardcfr-max-blocks= can set an upper limit for
For each block that is marked as visited, the mechanism checks that at least one of its predecessors, and at least one of its successors, are also marked as visited.
Verification is performed just before a subprogram returns. The following fragment:
if X then Y := F (Z); return; end if;
gets turned into:
type Visited_Bitmap is array (1..N) of Boolean with Pack; Visited : aliased Visited_Bitmap := (others => False); -- Bitmap of visited blocks. N is the basic block count. [...] -- Basic block #I Visited(I) := True; if X then -- Basic block #J Visited(J) := True; Y := F (Z); CFR.Check (N, Visited'Access, CFG'Access); -- CFR is a hypothetical package whose Check procedure calls -- libgcc's __hardcfr_check, that traps if the Visited bitmap -- does not hold a valid path in CFG, the run-time -- representation of the control flow graph in the enclosing -- subprogram. return; end if; -- Basic block #K Visited(K) := True;
Verification would also be performed before tail calls, if any front-ends marked them as mandatory or desirable, but none do. Regular calls are optimized into tail calls too late for this transformation to act on it.
In order to avoid adding verification after potential tail calls,
which would prevent tail-call optimization, we recognize returning
calls, i.e., calls whose result, if any, is returned by the calling
subprogram to its caller immediately after the call returns.
Verification is performed before such calls, whether or not they are
ultimately optimized to tail calls. This behavior is enabled by
default whenever sibcall optimization is enabled (see
-foptimize-sibling-calls); it may be disabled with
-fno-hardcfr-check-returning-calls, or enabled with
-fhardcfr-check-returning-calls, regardless of the
optimization, but the lack of other optimizations may prevent calls
from being recognized as returning calls:
-- CFR.Check here, with -fhardcfr-check-returning-calls. P (X); -- CFR.Check here, with -fno-hardcfr-check-returning-calls. return;
-- CFR.Check here, with -fhardcfr-check-returning-calls. R := F (X); -- CFR.Check here, with -fno-hardcfr-check-returning-calls. return R;
Any subprogram from which an exception may escape, i.e., that may
raise or propagate an exception that isn’t handled internally, is
conceptually enclosed by a cleanup handler that performs verification,
unless this is disabled with
With this feature enabled, a subprogram body containing:
-- ... Y := F (X); -- May raise exceptions. -- ... raise E; -- Not handled internally. -- ...
gets modified as follows:
begin -- ... Y := F (X); -- May raise exceptions. -- ... raise E; -- Not handled internally. -- ... exception when others => CFR.Check (N, Visited'Access, CFG'Access); raise; end;
Verification may also be performed before No_Return calls, whether
only nothrow ones, with
-fhardcfr-check-noreturn-calls=nothrow, or all of them, with
-fhardcfr-check-noreturn-calls=always. The default is
-fhardcfr-check-noreturn-calls=never for this feature, that
disables checking before No_Return calls.
When a No_Return call returns control to its caller through an
exception, verification may have already been performed before the
-fhardcfr-check-noreturn-calls=always is in effect.
The compiler arranges for already-checked No_Return calls without a
preexisting handler to bypass the implicitly-added cleanup handler and
thus the redundant check, but a local exception or cleanup handler, if
present, will modify the set of visited blocks, and checking will take
place again when the caller reaches the next verification point,
whether it is a return or reraise statement after the exception is
otherwise handled, or even another No_Return call.
The instrumentation for hardening with control flow redundancy can be
observed in dump files generated by the command-line option
For more details on the control flow redundancy command-line options, see Using the GNU Compiler Collection (GCC). These options can be used with other programming languages supported by GCC.