TIL about LLVM's ExpandInlineAsm via https://discourse.llvm.org/t/rfc-constant-time-coding-support/87781/37 (@lenary) and I'm more than a little horrified.
-
The ultimate reductio ad absurdum would be if we start putting machine code bytes in inline asm blocks only for compilers to eventually start "helpfully" disassembling them to perform intrinsic substitutions.
@pervognsen can't be too far… i've already had to do that when clang cleverly detected that my inline asm wasn't supported by the -march on the build line… sometimes I just don't want *the compiler* to use fancy stuff, even though it's available.
-
TIL about LLVM's ExpandInlineAsm via https://discourse.llvm.org/t/rfc-constant-time-coding-support/87781/37 (@lenary) and I'm more than a little horrified. Is nothing sacred?
@pervognsen @lenary There must be some cursed linker out there that inspects machine code bytes to make decisions rather than purely using relocations.
-
@pervognsen @lenary There must be some cursed linker out there that inspects machine code bytes to make decisions rather than purely using relocations.
@zwarich @pervognsen @lenary how about a rosetta-like jit that doesn't change ISAs but just messes with the instructions executed by the host architecture
-
@zwarich @pervognsen @lenary how about a rosetta-like jit that doesn't change ISAs but just messes with the instructions executed by the host architecture
@joe @pervognsen @lenary This is related to my craziest idea for a technically “memory safe” language. You’re allowed to do arbitrary native code execution from unsafe memory accesses, but it kicks you into a dynamically binary translated environment with runtime checks that only lets you return to executing “normal” code if all of your modifications to memory were type-safe.
-
@pervognsen @lenary There must be some cursed linker out there that inspects machine code bytes to make decisions rather than purely using relocations.
@zwarich @pervognsen let me introduce you to RISC-V Linker Relaxations, which both inspect and modify machine code bytes to change the sequence to better ones (they still use relocations)
-
@zwarich @pervognsen let me introduce you to RISC-V Linker Relaxations, which both inspect and modify machine code bytes to change the sequence to better ones (they still use relocations)
@lenary @pervognsen AArch64 linkers do similar things (e.g. NOPing out parts of multibyte sequences that compress when the displacement is small). Maybe RISC-V has some more interesting variants of this, though.
-
@lenary Yeah, found the comments on that in the proposed LangRef changes. It's good that this is at least getting nailed down.
@pervognsen I don't have data to back this up but I presume this exact inline asm string in the x86 callback was in a core header/library somewhere, called from a hot loop, and this made a specific benchmark faster on a machine that had a better core than the header presumed.
-
@lenary @pervognsen AArch64 linkers do similar things (e.g. NOPing out parts of multibyte sequences that compress when the displacement is small). Maybe RISC-V has some more interesting variants of this, though.
@zwarich @pervognsen nop-ing is fine compared to relaxation. AArch64 doesn't have variable-width instructions, and doesn't delete instructions during relaxation (shuffling everything afterwards)
-
@zwarich @pervognsen nop-ing is fine compared to relaxation. AArch64 doesn't have variable-width instructions, and doesn't delete instructions during relaxation (shuffling everything afterwards)
@zwarich @pervognsen risc-v will do things like rewrite registers in instructions, delete instructions, rewrite them with a smaller variant, etc etc etc. Now remember that alignment needs to be preserved and enjoy your headache.
-
The ultimate reductio ad absurdum would be if we start putting machine code bytes in inline asm blocks only for compilers to eventually start "helpfully" disassembling them to perform intrinsic substitutions.
@pervognsen I was literally about to ask "what if I did
.4byte ...?"
-
R relay@relay.infosec.exchange shared this topic
