search for: mretpolin

Heyho both Mailinglists, I'm not sure if I encountered a bug or if I'm doing something wrong. I compiled a "Hello World"-function with Clang to LLVM-IR code, while passing the "-mretpoline" flag. I tried jitting and calling that function with the KaleidoscopeJIT code, but when calling "lookup" for that function the application crashed. I also tried that file in an old MCJIT implementation I had - there the application crashed when calling the function (but it does fi...

...hunk >> ABI matching what GCC, the Linux kernel and Xen are all doing? >> >> To say that I am not stunningly keen on >> https://lkml.org/lkml/2018/2/2/975 would be a bit of an >> understatement... > > A minor note on this specific patch: You don't need '-mretpoline -mretpoline-external-thunk'. The second flag implies the first. (Or should, if not, its a bug.) Our goal was that you needed exactly one flag to enable this in whatever form. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llv...

...what GCC, the Linux kernel and Xen are all doing? > > To say that I am not stunningly keen on > https://lkml.org/lkml/2018/2/2/975 would be a bit of an > understatement... > > > A minor note on this specific patch: > > You don't need '-mretpoline -mretpoline-external-thunk'. The second flag implies the first. (Or should, if not, its a bug.) Our goal was that you needed exactly one flag to enable this in whatever form. The llvm commit log says: "... They can write this custom thunk and use `-mretpoline-external-thunk` *in additio...

...ll doing? > > > > To say that I am not stunningly keen on > > https://lkml.org/lkml/2018/2/2/975 would be a bit of an > > understatement... > > > > > > A minor note on this specific patch: > > > > You don't need '-mretpoline -mretpoline-external-thunk'. The second flag > implies the first. (Or should, if not, its a bug.) Our goal was that you > needed exactly one flag to enable this in whatever form. > > The llvm commit log says: > > "... They can write this custom thunk and use `-mretpoline...

...LVM and GCC can't possible release in sync, IMO they *should* use different names. I asked the GCC developers to include 'gcc' in the name, but at least the person I asked was not at all receptive. Two, I actually agree with you about the command line flags. I asked for it to be '-mretpoline'. I think a short, clear flag is really best, and we've very publicly documented this technique as 'retpoline'. But the GCC community has a fairly different design AFAICT... The only embedded thunks the offer are inline (ours are always out-of-line, even if they aren't external...

...> > configure checks to see if the linker accepts those flags, so my guess > is that something is added later in configure that causes it to fail. > I suggest looking at config.log to see what the actaul compiler > messages are from these parts: > > OSSH_CHECK_CFLAG_COMPILE([-mretpoline]) # clang > OSSH_CHECK_LDFLAG_LINK([-Wl,-z,retpolineplt]) > > and the actual compiler output show up in config.log. > > I wrote and tested this patch against the development versions of gcc > and clang which was all that was available at the time, it's possible > the rel...

I think I see what's going on, and I agree it looks like a bug. It was too much to hope that later passes weren't going to mess with the PUSH instruction. :( While I was trying to reproduce your problem, I think I found another one that looks like this: $ clang -S -O2 -m32 -mregparm=3 -mretpoline spill_across_rp.cpp -o - | grep _retpoline_push -B2 ... movl %eax, 8(%esp) # 4-byte Spill ... pushl %edi movl 8(%esp), %edi # 4-byte Reload calll __llvm_retpoline_push That's obviously broken, it doesn't account for the SP adju...

...rror 1 The ldflags check originates in cat configure.ac ... 164 if test "x$use_toolchain_hardening" = "x1"; then OSSH_CHECK_CFLAG_COMPILE([-mfunction-return=thunk]) # gcc OSSH_CHECK_CFLAG_COMPILE([-mindirect-branch=thunk]) # gcc OSSH_CHECK_CFLAG_COMPILE([-mretpoline]) # clang !! OSSH_CHECK_LDFLAG_LINK([-Wl,-z,retpolineplt]) OSSH_CHECK_CFLAG_COMPILE([-D_FORTIFY_SOURCE=2]) OSSH_CHECK_LDFLAG_LINK([-Wl,-z,relro]) ... I've not had any issues, yet, with any other of many packages I build with this GCC env; this fail is, so far, unique to this o...

...extend existing mechanisms for controlling layout that are used to implement CFI (see https://clang.llvm.org/docs/ControlFlowIntegrityDesign.html) so that they are also used whenever a branch funnel needs to be created. The compiler will only use branch funnels when both the retpoline mitigation (-mretpoline) and whole-program devirtualization (-fwhole-program-vtables) features are enabled (the former is on the assumption that in general a regular indirect call will be less expensive than a branch funnel, and the latter provides the necessary guarantee that the type hierarchy is closed). Even when ret...

...t], [-Wno-unused-result]) OSSH_CHECK_CFLAG_COMPILE([-fno-strict-aliasing]) if test "x$use_toolchain_hardening" = "x1"; then + OSSH_CHECK_CFLAG_COMPILE([-mfunction-return=thunk]) # gcc + OSSH_CHECK_CFLAG_COMPILE([-mindirect-branch=thunk]) # gcc + OSSH_CHECK_CFLAG_COMPILE([-mretpoline]) # clang + OSSH_CHECK_CFLAG_LINK([-z retpolineplt]) # clang OSSH_CHECK_CFLAG_COMPILE([-D_FORTIFY_SOURCE=2]) OSSH_CHECK_LDFLAG_LINK([-Wl,-z,relro]) OSSH_CHECK_LDFLAG_LINK([-Wl,-z,now]) -- Darren Tucker (dtucker at dtucker.net) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11E...

...ms for controlling layout that are used to implement CFI > (see https://clang.llvm.org/docs/ControlFlowIntegrityDesign.html) so that > they are also used whenever a branch funnel needs to be created. > > The compiler will only use branch funnels when both the retpoline > mitigation (-mretpoline) and whole-program devirtualization > (-fwhole-program-vtables) features are enabled (the former is on the > assumption that in general a regular indirect call will be less expensive > than a branch funnel, and the latter provides the necessary guarantee that > the type hierarchy is cl...

On Thu, 2018-02-01 at 10:10 +0100, Hans Wennborg via llvm-dev wrote: > > I saw the retpoline mitigation landed in r323155. Are we ready to > merge this to 6.0, or are there any open issues that we're waiting > for? Also, were there any followups I should know about? Also, > release notes please :-) Eep, please can we keep the command line option for clang and the thunk ABI

On Sat, 2018-02-03 at 00:51 +0000, Chandler Carruth wrote: > While you *can* export your external thunk, that's a choice of the > code defining the thunk. The driving force in the kernel is to be able to runtime patch the thunks away, when running on a CPU or in a mode that doesn't need them. We really want to have central implementations and have everything use them. > >

...docs/ControlFlowIntegrityDesign.html > <https://clang.llvm.org/docs/ControlFlowIntegrityDesign.html>) so > that they are also used whenever a branch funnel needs to be created. > > The compiler will only use branch funnels when both the retpoline > mitigation (-mretpoline) and whole-program devirtualization > (-fwhole-program-vtables) features are enabled (the former is on the > assumption that in general a regular indirect call will be less > expensive than a branch funnel, and the latter provides the > necessary guarantee that the type...

...on, and I agree it looks like a bug. It was too > much to hope that later passes weren't going to mess with the PUSH > instruction. :( > > While I was trying to reproduce your problem, I think I found another one > that looks like this: > > $ clang -S -O2 -m32 -mregparm=3 -mretpoline spill_across_rp.cpp -o - | grep > _retpoline_push -B2 > ... > movl %eax, 8(%esp) # 4-byte Spill > ... > pushl %edi > movl 8(%esp), %edi # 4-byte Reload > calll __llvm_retpoline_push > > That's obviously br...

...ort loadable modules which > attempt to use the thunks by different names to the function that's > exported. I'm not sure how we'd hack up the unresolved symbols in the > module objects to match the exported symbol names. > I had actually wanted to originally have the '-mretpoline-external-thunk' flag take a completely custom name for the thunks on the command line. Unfortunately, that proved remarkably annoying to implement in LLVM (for pretty silly reasons, but it is what it is). I didn't do that in large part because it seemed easy for users of external thunks to...

On Fri, 2018-02-09 at 11:24 -0800, Reid Kleckner wrote: > I haven't read the all the emails in full detail, but it seems pretty > clear that  __x86_indirect_thunk and __llvm_retpoline_push do not do > the same things. It sounds like __llvm_retpoline_push is equivalent > to __x86_indirect_thunk except first it swaps the two words on the > top of the stack. > > I arranged

On Tue, Feb 6, 2018 at 4:46 PM David Woodhouse <dwmw2 at infradead.org> wrote: > On Wed, 2018-02-07 at 00:36 +0000, Chandler Carruth wrote: > > > > > > > That would be __x86_indirect_thunk but the kernel doesn't use it. > > > We use -mindirect-branch-register and only ever expect the compiler > > > to use the register versions which are

Hi all, I encountered an error while compiling Linux kernel 5.3 to IR. My LLVM version is 9.0.0 release. This error said "invalid operand for inline asm constraint 'i'" in arch/x86/include/asm/jump_table.h. The source code is static __always_inline bool arch_static_branch(struct static_key *key, bool branch) { asm_volatile_goto("1:" ".byte "

Hi all, I saw the retpoline mitigation landed in r323155. Are we ready to merge this to 6.0, or are there any open issues that we're waiting for? Also, were there any followups I should know about? Also, release notes please :-) Thanks, Hans -------------- next part -------------- An HTML attachment was scrubbed... URL: