From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) by sourceware.org (Postfix) with ESMTPS id A591F3858292 for ; Mon, 11 Jul 2022 07:47:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A591F3858292 Received: by mail-qt1-x836.google.com with SMTP id l2so2892798qtp.11 for ; Mon, 11 Jul 2022 00:47:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=98rMmOSx9coH+b/bPwymmUQ1UPH6eipAugbov5dzqEM=; b=rLR53vPogoGEY4y80BI/Yg1jYhxxhMLCO6w9rF2CkWHHAvg/SlSPRITMSAGpNDH4dq oSZ3Z0O5vM4I36vfvf6zl/7UAb94+rjrgOGTHZdOKseX3gWRSvcSSmil6KpvyMwZMVCt qDzvyt0/B7jjBzlceSE/494y6rVyE/22dm4IreoctYPYryhKz+YxYA+7WVwYHtCqjzVU 7dvhlNYgBU08Dz3h5ZoKTG0EZ8bC8kiOoiRFW+HDz+8OGSxtm30pUoRv2/c6acAcWHma 1gLXsBJO0qdA/qGOtj8XrS/GLp24xi9VrQF4SSUqHP2KZ77oqtf0WqWjCOwHwnYomJih GYdw== X-Gm-Message-State: AJIora9Uor6JGXyRBbXbtFXyh081OTsiWYT+K4lV/ESF0/+OFUYTuF5m 5nGALHOABG3ZfPsbJYahVoMnvHsSa7cZ0Sov+nk= X-Google-Smtp-Source: AGRyM1vanojIgnnj6LnHGReM67sEGtNjJQfMtFhOXAnfbS3dyUh8W+to9/wT44+PJFnqM00Bac7Hmmj3ThFqGcan2XM= X-Received: by 2002:a05:622a:c7:b0:31d:47d3:526 with SMTP id p7-20020a05622a00c700b0031d47d30526mr12621096qtw.581.1657525653943; Mon, 11 Jul 2022 00:47:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Mon, 11 Jul 2022 09:47:22 +0200 Message-ID: Subject: Re: [PATCH] Control flow redundancy hardening To: Alexandre Oliva Cc: GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2022 07:47:36 -0000 On Fri, Jul 8, 2022 at 7:00 PM Alexandre Oliva wrote: > > On Jul 8, 2022, Richard Biener 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