JIT should allow producing CFG/XFG-enabled binaries

[GrabYourPitchforks]

There have been some requests from partners to enable RyuJIT to produce CFG-enabled codegen. As AOT scenarios become more prevalent and the JIT becomes closer to a true "native" compiler, this would also match the CFG protections afforded by the MSVC compiler. This is a tracking issue for those requests.

Related: #29880, but that tracks annotating CLR binaries rather than controlling the JIT codegen.

[jkotas]

We have internal planning documents about this. Some of the key points:

• There is no point in doing CFG without W^X (tracked by Make CoreCLR compatible with W^X #10036). Lack of W^X is much easier target than lack of CFG. We would want to do W^X first.
• It is not clear how CFG should be applied to managed code.

cc @janvorli @jeffschwMSFT

[mababey]

We notice this omission for our UWP app project. We run BinSkim on the .NET Native compiled binaries, and it flags the lack of CFG mitigation.

While CFG mitigation might not apply to the original managed code, once compiled, we're effectively trusting that the translation to machine code by RyuJIT doesn't result in potentially vulnerable indirect call targets.

(I'm not familiar with the implementation details of the JIT compiler to know whether there are other factors which void that concern.)

[GrabYourPitchforks]

Related: Windows now has preliminary support for CET. We may wish to investigate turning this on for our code bases. See https://techcommunity.microsoft.com/t5/windows-kernel-internals/understanding-hardware-enforced-stack-protection/ba-p/1247815 for more info.

[jkotas]

We have been investigating the CET support for some time. It is not a simple recompile. There are number of changes required in how e.g. exception handling or GC suspension works. Also, new OS APIs are needed to make it possible.

[jakobbotsch]

Can this issue be closed, or is it still tracking the CET work?