IBT/BTI instructions and D compilers (page 3)

On Monday, 10 July 2023 at 19:54:59 UTC, Walter Bright wrote: > On 7/10/2023 5:16 AM, Brian Callahan wrote: >> All good. I'm just asking about the status of IBT/BTI instructions being emitted by DMD and LDC. That's all. > > Are you talking about the ENDBR32 and ENDBR64 instructions? Yes. Intel's documentation on this is terrible https://edc.intel.com/content/www/us/en/design/ipla/software-development-platforms/client/platforms/alder-lake-desktop/12th-generation-intel-core-processors-datasheet-volume-1-of-2/006/indirect-branch-tracking/

July 11, 2023

Re: IBT/BTI instructions and D compilers

Posted by Ernesto Castellotti
in reply to Iain Buclaw

Permalink

Ernesto Castellotti

Posted in reply to Iain Buclaw

Permalink

On Monday, 10 July 2023 at 14:17:36 UTC, Iain Buclaw wrote:

On Monday, 10 July 2023 at 11:24:37 UTC, Brian Callahan wrote:

Hi all (but probably mostly Walter) --

OpenBSD has moved to an all-BTI world. Binaries produced by DMD and LDC no longer work because of this. If other OSes make this move, this problem will be further compounded. Is there any thought about enabling IBT/BTI instructions in DMD and LDC?

Thanks.

This is Intel CET, right?

It's on by default at configure-time.

https://github.com/gcc-mirror/gcc/commit/08c1d39d3a822dfe7d91524ec290e0f230504242

Speaking of which, the asm support code for Fibers does not support shadow stacks, so you'll need to fall back to ucontext_t's swapcontext unless someone figures out what the correct way to handle it is.

There is also for AArch64, see -mbranch-protection.
GCC/GDC works fine with -mbranch-protection on AArch64 but I don't know if it's the default.

On 7/10/2023 4:24 AM, Brian Callahan wrote: > OpenBSD has moved to an all-BTI world. Binaries produced by DMD and LDC no longer work because of this. If other OSes make this move, this problem will be further compounded. Is there any thought about enabling IBT/BTI instructions in DMD and LDC? Illuminating Hacker News discussion of this feature: https://news.ycombinator.com/item?id=36722823

On 7/10/2023 5:46 AM, Ernesto Castellotti wrote: > Regarding DMD I think it's very complex because probably the backend doesn't support it. Ye of little faith! 20 lines of code. https://github.com/dlang/dmd/pull/15415

Ooooo are we challenging you to things that dmd-be can't possibly support and you proving us wrong? Okay, I'll begin: dmd-be cannot support atomics as intrinsics. How do I know this? You're too clever to have not implemented it if it was possible and instead had to rely on the slow non-inlining memory segfaulting inline assembly instead. After all, if ldc and gdc both support it and dmd doesn't, it must be because it can't do it!

On Saturday, 15 July 2023 at 05:09:42 UTC, Walter Bright wrote: > On 7/10/2023 5:46 AM, Ernesto Castellotti wrote: >> Regarding DMD I think it's very complex because probably the backend doesn't support it. > > Ye of little faith! 20 lines of code. > > https://github.com/dlang/dmd/pull/15415 Hi Walter -- Thanks for working on this! It is much appreciated. I'll have some time soon to test it and LDC out. (Also, I'd like to apologize to Rikki for my initial response on this thread. Came off harsher than I intended it to.) ~Brian

On 16/07/2023 12:22 AM, Brian Callahan wrote: > (Also, I'd like to apologize to Rikki for my initial response on this thread. Came off harsher than I intended it to.) Lol its all good. You were in the throws of trying to get a pretty important improvement allocated time for, and I was worrying about WinCrypt so certain details were forgotten at the time :)

On 7/14/2023 11:41 PM, Richard (Rikki) Andrew Cattermole wrote: > Ooooo are we challenging you to things that dmd-be can't possibly support and you proving us wrong? The dmd back end started out as an 8086 code generator. It survived: 1. adding 8087 instruction set (very different) 2. upgrade to 286 3. upgrade to 32 bit code 4. upgrade to 64 bit code 5. upgrade to SIMD 6. upgrade to VEX

Forums