Re: [PATCH] Control flow redundancy hardening

[Richard Biener <richard.guenther@gmail.com>]

On Fri, Jul 8, 2022 at 7:00 PM Alexandre Oliva <oliva@adacore.com> wrote:
>
> On Jul  8, 2022, Richard Biener <richard.guenther@gmail.com> wrote:
>
> > I'm possibly missing the importance of 'redundancy' in -fharden-control-flow
>
> I took "Control Flow Redundancy" as a term of the art and never
> questioned it.  I think the "redundancy" has to do with the fact that
> control flow is generally affected by tests and conditionals, and the
> checks that an expected path was seemingly taken is redundant with
> those.
>
> > but how can you, from a set of visited blocks local to a function,
> > determine whether the control flow through the function is "expected"
>
> Hmm, maybe the definition should be in the negated form: what the check
> catches is *unexpected* execution flows, e.g. when a block that
> shouldn't have been reached (because none of its predecessors was)
> somehow was.  This unexpected circumstance indicates some kind of fault
> or attack, which is what IIUC this check is about.
>
> Whether the fault was that the hardware took a wrong turn because it was
> power deprived, or some software exploit returned to an artifact at the
> end of a function to get it to serve an alternate purpose, the check at
> the end of the function would catch the unexpected execution of a block
> that couldn't be reached under normal circumstances, and flag the error
> before further damage occurs.
>
> > Can you elaborate on what kind of "derailed" control flow this catches
> > (example?) and what cases it does not?
>
> As in the comments for the pass: for each visited block, check that at
> least one predecessor and at least one successor were also visited.

I see.  So for all of the above being a bit more elaborate in the
documentation might be nice.  Still 'harden' and 'redundancy'
in -fharden-control-flow-redundancy sound redundant, depending
on the target audience -fharden-control-flow or -fcontrol-flow-redundancy
might be a good fit.

> > I'm also curious as of how this compares to hardware
> > mitigations like x86 indirect branch tracking and shadow stack
>
> I'm not expert in the field, but my understanding is that these are
> complementary.
>
> Indirect branch tracking constrains the set of available artifacts one
> might indirectly branch to, but if you reach one of them, you'd be no
> wiser that something fishy was going on without checking that you got
> there from some of the predecessor blocks.  (we don't really check
> precisely that, nor do we check at that precise time, but we check at
> the end of the function that at least one of the predecessor blocks was
> run.)  Constraining the available indirect branch targets helps avoid
> bypassing the code that sets the bit corresponding to that block, which
> might enable an attacker to use an artifact without detection., if
> there's no subsequent block that would be inexplicably reached.
>
> Shadow stacks avoid corruption of return addresses, so you're less
> likely to reach an unexpected block by means of buffer overruns that
> corrupt the stack and overwrite the return address.  Other means to land
> in the middle of a function, such as corrupting memory or logical units
> through power deprivation remain, and this pass helps guard against
> those too.
>
> > and how this relates to the LLVM control flow hardening (ISTR such
> > thing exists).
>
> I've never heard of it.  I've just tried to learn about it, but I
> couldn't find anything pertinent.
>
> Are you by any chance thinking of
> https://clang.llvm.org/docs/ControlFlowIntegrity.html
> ?

Yeah, I probably thought of this ...

> This appears to be entirely unrelated: the control flow nodes it's
> concerned with are functions/methods/subprograms in a program, rather
> than basic blocks within a function.
>
>
> Thanks a lot for these questions.  They're going to help me be better
> prepared for a presentation about various hardening features (*) that
> I've submitted and am preparing for the upcoming Cauldron.

Heh, I was about to suggest that!

Richard.

> (*) https://docs.adacore.com/live/wave/gnat_rm/html/gnat_rm/gnat_rm/security_hardening_features.html
>
> --
> Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
>    Free Software Activist                       GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about <https://stallmansupport.org>