Please add support for Intel CET

[xnox]

https://www.linuxplumbersconf.org/event/2/contributions/147/attachments/72/83/CET-LPC-2018.pdf

When compiling C binaries with -fcf-protection the binaries are generated with Indirect Branch Tracking (IBT) Shadow Stack (SHSTK) features, and are thus CET enabled.

I cannot find a way for rustc compiler to generate binaries with the gnu properties declared on the ELF binary, but also have the right endbranch instructions emitted.

$ cat empty.c 
void main(){}
$ cat empty.rs 
fn main(){}
$ gcc -fcf-protection -o gcc-c empty.c
$ clang -fcf-protection -o clang-c empty.c
$ rustc  -o rustc empty.rs
$ readelf -a gcc-c | grep feature:
      Properties: x86 feature: IBT, SHSTK
$ readelf -a clang-c | grep feature:
      Properties: x86 feature: IBT, SHSTK
$ readelf -a rustc | grep feature:
$ echo $?
1

Trying to set CFLAGS/LDFLAGS/RUSTFLAGS did not make rustc compiler generate CET enabled binaries, thus I am assuming that rustc does not have support for CET.

I looked through the available codegen options and also did not find a way to generate CET enabled binaries.

Please add support for rustc to generate CET enabled binaries, when toolchain has support for it. Or please document how to make rustc do so, because gcc / LLVM and linkers have support for it.

[xnox]

@hjl-tools not sure if you want to track this too.

[hjl-tools]

CET support in compiler is mostly implemented during codegen in the x86 backend. If rust frontend can properly pass
-fcf-protection to the x86 backend, CET should just work. Another piece is the run-time library. If the rust run-time library
has any assembly codes, they must be enabled with CET.

BTW, LLVM 11 is needed for working CET support. LLVM 10.x should be OK. LLVM 10.0 doesn't have a working CET
implementation. Also libuwind in LLVM dosn't support CET:

https://bugs.llvm.org/show_bug.cgi?id=45946

[cuviper]

If the rust run-time library has any assembly codes, they must be enabled with CET.

I think that probably applies to __rust_probestack. However, in LLVM 11 we can switch that to LLVM's inline stack probes, and then I think we'll be absolved.

[cgwalters]

I stumbled on this because Fedora/RHEL run https://sourceware.org/annobin/annobin.html/Test-cf-protection.html as part of builds and it flags Rust code as not using CET.

My initial thought was that trying this out would just be a matter of e.g. rustc -C "llvm-args=-fcf-protection" -o empty empty.rs but it seems to me that right now in LLVM the CLI option is part of clang and not a common codegen option or so? So probably it'd require a bit of minor plumbing, I am not familiar enough with the codebase but I think it'd be a new custom option in configure_llvm()?

[cuviper]

I found that Clang supports this by adding LLVM module flags, "cf-protection-branch" and "cf-protection-return". At a first attempt at hard-coding these, it does seem to work, producing a binary with this note:

Displaying notes found in: .note.gnu.property
  Owner                Data size        Description
  GNU                  0x00000020       NT_GNU_PROPERTY_TYPE_0
      Properties: x86 feature: IBT, SHSTK
        x86 ISA needed: x86-64-baseline

I'm still testing, but if this works I'll see about a -Z option for it. I think it will need to be enabled by default to be useful.

[teknoman117]

I don't know if this is related, but on rust 1.56.1, 1.57, and 1.58 (only ones I've tried), I'm getting CET opcodes where I don't want them #93059 (the i586 target)

[abrown]

Oops, I just pushed a draft PR with initial support for CET but also several questions to resolve--apologies to @cuviper! Last I checked this thread was last year and I thought no one was working on this. @cuviper, or anyone who is interested, I would appreciate your comments on #93439 if you have a chance.

[cuviper]

@abrown No worries, I had lost my initial momentum. Thanks for picking it up!

[abrown]

@xnox and all: #93439 adds initial support for CET behind the -Z cf-protection flag. More information is available here and will presumably be available in the unstable book once the next version is released. Even though the availability of this flag is pending that release (unless you build rustc from source or use nightly), I propose we close this issue and continue the discussion in the tracking issue I created, #93754. I'm interested in getting feedback from all of you on the remaining parts needed to make this a stable flag (-C cf-protection).

[Dylan-DPC]

Closing this in favour of the tracking issue linked above