From: "joao@overdrivepizza.com" <joao@overdrivepizza.com>
To: "Kees Cook" <keescook@chromium.org>
Cc: kernel-hardening@lists.openwall.com,
vasileios_kemerlis@brown.edu, sandro@ic.unicamp.br
Subject: Re: kCFI sources
Date: Sat, 04 Apr 2020 03:28:15 +0200 [thread overview]
Message-ID: <df8-5e87e280-b3-1e9bdee0@78115022> (raw)
In-Reply-To: <202004031626.B2FDF354@keescook>
> Weren't there updates make to LLVM to provide a more fine-grained
> bucketization of the function prototypes? (i.e. instead of all "void
> func(void)" being in one bucket, they got chopped into more buckets?)
The optimization we put in place (Call Graph Detaching) in the shared sources has a slightly different goal. It uses both source-level and binary-level information (not only changes in llvm) to identify which functions belonging to a prototype group are callable both directly and indirectly (they have a matching function pointer and a direct call); then it clones these functions and replace the direct call to them with a direct call to the clone. By doing so, it allows the function to have a different tag to be checked on return in each of its versions, detaching the instances of the function invocation from the prototype group. This reduces the the number of allowed return targets of the cloned functions to the actual number of direct calls to it, instead of the number of indirect and direct calls to the whole prototype group. This is actually a backward-edge granularity optimization.
For examples, see slides 28-33: https://www.blackhat.com/docs/asia-17/materials/asia-17-Moreira-Drop-The-Rop-Fine-Grained-Control-Flow-Integrity-For-The-Linux-Kernel.pdf
prev parent reply other threads:[~2020-04-04 10:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-03 5:29 kCFI sources joao
2020-04-03 23:28 ` Kees Cook
2020-04-04 1:28 ` joao [this message]
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=df8-5e87e280-b3-1e9bdee0@78115022 \
--to=joao@overdrivepizza.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=sandro@ic.unicamp.br \
--cc=vasileios_kemerlis@brown.edu \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.