public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Alexandre Oliva <aoliva@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc(refs/users/aoliva/heads/testme)] hardcfr: prevent deferred sets of visited bitmap Date: Fri, 9 Jun 2023 06:17:07 +0000 (GMT) [thread overview] Message-ID: <20230609061707.D5C9E3857011@sourceware.org> (raw) https://gcc.gnu.org/g:7dd60c2f0a42a9664baabcde0b345b3a6f94f46f commit 7dd60c2f0a42a9664baabcde0b345b3a6f94f46f Author: Alexandre Oliva <oliva@adacore.com> Date: Thu Jun 8 01:35:23 2023 -0300 hardcfr: prevent deferred sets of visited bitmap Make bitmap sets volatile-ish, preventing deferral and likely combinations. for gcc/ChangeLog * gimple-harden-control-flow.cc (rt_bb_visited::rt_bb_visited): Move optimization barrier... (rt_bb_visited::vset): ... here. Diff: --- gcc/gimple-harden-control-flow.cc | 48 ++++++++++++++++++++++++--------------- 1 file changed, 30 insertions(+), 18 deletions(-) diff --git a/gcc/gimple-harden-control-flow.cc b/gcc/gimple-harden-control-flow.cc index 53717a652ca..3e6fe2db479 100644 --- a/gcc/gimple-harden-control-flow.cc +++ b/gcc/gimple-harden-control-flow.cc @@ -545,6 +545,36 @@ class rt_bb_visited gassign *vstore = gimple_build_assign (unshare_expr (setme), temp); gimple_seq_add_stmt (&seq, vstore); + /* Prevent stores into visited from being deferred, forcing + subsequent bitsets to reload the word rather than reusing + values already in register. The purpose is threefold: make the + bitset get to memory in this block, so that control flow + attacks in functions called in this block don't easily bypass + the bitset; prevent the bitset word from being retained in a + register across blocks, which could, in an attack scenario, + make a later block set more than one bit; and prevent hoisting + or sinking loads or stores of bitset words out of loops or even + throughout functions, which could significantly weaken the + verification. This is equivalent to making the bitsetting + volatile within the function body, but without changing its + type; making the bitset volatile would make inline checking far + less optimizable for no reason. */ + vec<tree, va_gc> *inputs = NULL; + vec<tree, va_gc> *outputs = NULL; + vec_safe_push (outputs, + build_tree_list + (build_tree_list + (NULL_TREE, build_string (2, "=m")), + visited)); + vec_safe_push (inputs, + build_tree_list + (build_tree_list + (NULL_TREE, build_string (1, "m")), + visited)); + gasm *stabilize = gimple_build_asm_vec ("", inputs, outputs, + NULL, NULL); + gimple_seq_add_stmt (&seq, stabilize); + return seq; } @@ -615,24 +645,6 @@ public: tree visited_type = vtype (); visited = create_tmp_var (visited_type, ".cfrvisited"); - /* Prevent stores into visited from being used to optimize the - control flow redundancy checks. asm ("" : "+m" (visited)); */ - vec<tree, va_gc> *inputs = NULL; - vec<tree, va_gc> *outputs = NULL; - vec_safe_push (outputs, - build_tree_list - (build_tree_list - (NULL_TREE, build_string (2, "=m")), - visited)); - vec_safe_push (inputs, - build_tree_list - (build_tree_list - (NULL_TREE, build_string (1, "m")), - visited)); - gasm *detach = gimple_build_asm_vec ("", inputs, outputs, - NULL, NULL); - gimple_seq_add_stmt (&ckseq, detach); - if (nblocks - NUM_FIXED_BLOCKS > blknum (param_hardcfr_max_inline_blocks) || checkpoints > 1) {
next reply other threads:[~2023-06-09 6:17 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-06-09 6:17 Alexandre Oliva [this message] -- strict thread matches above, loose matches on Subject: below -- 2023-06-09 8:07 Alexandre Oliva 2023-06-08 10:59 Alexandre Oliva 2023-06-08 10:43 Alexandre Oliva 2023-06-08 9:17 Alexandre Oliva 2023-06-08 4:47 Alexandre Oliva 2022-10-25 2:52 Alexandre Oliva 2022-10-20 22:32 Alexandre Oliva 2022-10-20 5:46 Alexandre Oliva 2022-10-20 4:09 Alexandre Oliva
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20230609061707.D5C9E3857011@sourceware.org \ --to=aoliva@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).