* arm64 kvm built with clang doesn't boot @ 2018-03-16 13:49 Andrey Konovalov 2018-03-16 14:13 ` Mark Rutland 2018-03-16 14:13 ` Marc Zyngier 0 siblings, 2 replies; 14+ messages in thread From: Andrey Konovalov @ 2018-03-16 13:49 UTC (permalink / raw) To: Nick Desaulniers, Stephen Hines, Greg Hackmann, Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon, Linux ARM, kvmarm, LKML, Mark Rutland Cc: kernel-dynamic-tools Hi! I've recently tried to boot clang built kernel on real hardware (Odroid C2 board) instead of using a VM. The issue that I stumbled upon is that arm64 kvm built with clang doesn't boot. Adding -fno-jump-tables compiler flag to arch/arm64/kvm/* helps. There was a patch some time ago that did exactly that (https://patchwork.kernel.org/patch/10060381/), but it wasn't accepted AFAICT (see the discussion on that thread). What would be the best way to get this fixed? I've also had to disable CONFIG_JUMP_LABEL to get the kernel boot (even without kvm enabled), but that might be a different (though related) issue. Thanks! ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: arm64 kvm built with clang doesn't boot 2018-03-16 13:49 arm64 kvm built with clang doesn't boot Andrey Konovalov @ 2018-03-16 14:13 ` Mark Rutland 2018-03-16 14:31 ` Mark Rutland 2018-03-16 14:50 ` Andrey Konovalov 2018-03-16 14:13 ` Marc Zyngier 1 sibling, 2 replies; 14+ messages in thread From: Mark Rutland @ 2018-03-16 14:13 UTC (permalink / raw) To: Andrey Konovalov Cc: Nick Desaulniers, Stephen Hines, Greg Hackmann, Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon, Linux ARM, kvmarm, LKML, kernel-dynamic-tools On Fri, Mar 16, 2018 at 02:49:00PM +0100, Andrey Konovalov wrote: > Hi! Hi, > I've recently tried to boot clang built kernel on real hardware > (Odroid C2 board) instead of using a VM. The issue that I stumbled > upon is that arm64 kvm built with clang doesn't boot. > > Adding -fno-jump-tables compiler flag to arch/arm64/kvm/* helps. There > was a patch some time ago that did exactly that > (https://patchwork.kernel.org/patch/10060381/), but it wasn't accepted > AFAICT (see the discussion on that thread). > > What would be the best way to get this fixed? I think that patch is our best bet currently, but to save ourselves pain in future it would be *really* nice if GCC and clang could provide an option line -fno-absolute-addressing that would implicitly disable any feature that would generate an absolute address as jump tables do. > I've also had to disable CONFIG_JUMP_LABEL to get the kernel boot > (even without kvm enabled), but that might be a different (though > related) issue. With v4.15 (and clang 5.0.0), I did not have to disable jump labels to get a kernel booting on a Juno platform, though I did have to pass -fno-jump-tables to the hyp code. Which kernel version and clang version are you using? Thanks, Mark. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: arm64 kvm built with clang doesn't boot 2018-03-16 14:13 ` Mark Rutland @ 2018-03-16 14:31 ` Mark Rutland 2018-03-16 14:55 ` Andrey Konovalov 2018-04-12 17:35 ` Andrey Konovalov 2018-03-16 14:50 ` Andrey Konovalov 1 sibling, 2 replies; 14+ messages in thread From: Mark Rutland @ 2018-03-16 14:31 UTC (permalink / raw) To: Andrey Konovalov Cc: Nick Desaulniers, Stephen Hines, Greg Hackmann, Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon, Linux ARM, kvmarm, LKML, kernel-dynamic-tools On Fri, Mar 16, 2018 at 02:13:14PM +0000, Mark Rutland wrote: > On Fri, Mar 16, 2018 at 02:49:00PM +0100, Andrey Konovalov wrote: > > Hi! > > Hi, > > > I've recently tried to boot clang built kernel on real hardware > > (Odroid C2 board) instead of using a VM. The issue that I stumbled > > upon is that arm64 kvm built with clang doesn't boot. > > > > Adding -fno-jump-tables compiler flag to arch/arm64/kvm/* helps. There > > was a patch some time ago that did exactly that > > (https://patchwork.kernel.org/patch/10060381/), but it wasn't accepted > > AFAICT (see the discussion on that thread). > > > > What would be the best way to get this fixed? > > I think that patch is our best bet currently, but to save ourselves pain > in future it would be *really* nice if GCC and clang could provide an > option line -fno-absolute-addressing that would implicitly disable any > feature that would generate an absolute address as jump tables do. > > > I've also had to disable CONFIG_JUMP_LABEL to get the kernel boot > > (even without kvm enabled), but that might be a different (though > > related) issue. > > With v4.15 (and clang 5.0.0), I did not have to disable jump labels to > get a kernel booting on a Juno platform, though I did have to pass > -fno-jump-tables to the hyp code. FWIW, with that same compiler and patch applied atop of v4.16-rc4, and some bodges around clang not liking the rX register naming in the SMCCC code, I get a kernel that boots on my Juno, though I immediately hit a KASAN splat: [ 8.476766] ================================================================== [ 8.483990] BUG: KASAN: slab-out-of-bounds in __d_lookup_rcu+0x350/0x400 [ 8.490664] Read of size 8 at addr ffff8009336e2a30 by task init/1 [ 8.496808] [ 8.498313] CPU: 2 PID: 1 Comm: init Not tainted 4.16.0-rc4-00001-g1e3a801c4e30-dirty #1 [ 8.506361] Hardware name: ARM Juno development board (r1) (DT) [ 8.512248] Call trace: [ 8.514699] dump_backtrace+0x0/0x29c [ 8.518356] show_stack+0x20/0x2c [ 8.521667] dump_stack+0x118/0x15c [ 8.525151] print_address_description+0x80/0x2d0 [ 8.529839] kasan_report+0x208/0x278 [ 8.533492] __asan_load8+0x1b0/0x1b8 [ 8.537148] __d_lookup_rcu+0x350/0x400 [ 8.540974] lookup_fast+0x19c/0x780 [ 8.544541] walk_component+0x108/0x121c [ 8.548452] path_lookupat+0x1a4/0x620 [ 8.552197] filename_lookup+0x1d8/0x440 [ 8.556113] user_path_at_empty+0x54/0x68 [ 8.560112] vfs_statx+0x108/0x1f0 [ 8.563507] SyS_newfstatat+0x118/0x19c [ 8.567333] el0_svc_naked+0x30/0x34 [ 8.570889] [ 8.572380] Allocated by task 1: [ 8.575603] kasan_kmalloc+0xe0/0x1ac [ 8.579259] __kmalloc+0x1e4/0x278 [ 8.582656] __d_alloc+0x8c/0x370 [ 8.585968] d_alloc_parallel+0xdc/0xca0 [ 8.589883] nfs_readdir_xdr_to_array+0xe44/0x1694 [ 8.594658] nfs_readdir_filler+0x44/0xe8 [ 8.598662] do_read_cache_page+0x450/0x6f4 [ 8.602836] read_cache_page+0x44/0x54 [ 8.606575] nfs_readdir+0xd58/0xef4 [ 8.610143] iterate_dir+0x15c/0x26c [ 8.613711] SyS_getdents64+0x180/0x30c [ 8.617538] el0_svc_naked+0x30/0x34 [ 8.621093] [ 8.622584] Freed by task 0: [ 8.625451] (stack is not available) [ 8.629007] [ 8.630505] The buggy address belongs to the object at ffff8009336e2a00 [ 8.630505] which belongs to the cache kmalloc-128 of size 128 [ 8.642969] The buggy address is located 48 bytes inside of [ 8.642969] 128-byte region [ffff8009336e2a00, ffff8009336e2a80) [ 8.654558] The buggy address belongs to the page: [ 8.659335] page:ffff7e0024cdb880 count:1 mapcount:0 mapping:0000000000000000 index:0x0 [ 8.667304] flags: 0x1fffc00000000100(slab) [ 8.671487] raw: 1fffc00000000100 0000000000000000 0000000000000000 0000000100100010 [ 8.679206] raw: dead000000000100 dead000000000200 ffff800937403c00 0000000000000000 [ 8.686907] page dumped because: kasan: bad access detected [ 8.692447] [ 8.693935] Memory state around the buggy address: [ 8.698710] ffff8009336e2900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8.705902] ffff8009336e2980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 8.713093] >ffff8009336e2a00: 00 00 00 00 00 00 06 fc fc fc fc fc fc fc fc fc [ 8.720277] ^ [ 8.725051] ffff8009336e2a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 8.732242] ffff8009336e2b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8.739426] ================================================================== Thanks, Mark. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: arm64 kvm built with clang doesn't boot 2018-03-16 14:31 ` Mark Rutland @ 2018-03-16 14:55 ` Andrey Konovalov 2018-04-12 17:35 ` Andrey Konovalov 1 sibling, 0 replies; 14+ messages in thread From: Andrey Konovalov @ 2018-03-16 14:55 UTC (permalink / raw) To: Mark Rutland Cc: Nick Desaulniers, Stephen Hines, Greg Hackmann, Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon, Linux ARM, kvmarm, LKML, kernel-dynamic-tools On Fri, Mar 16, 2018 at 3:31 PM, Mark Rutland <mark.rutland@arm.com> wrote: > > FWIW, with that same compiler and patch applied atop of v4.16-rc4, and > some bodges around clang not liking the rX register naming in the SMCCC > code, I get a kernel that boots on my Juno, though I immediately hit a > KASAN splat: > > [ 8.476766] ================================================================== > [ 8.483990] BUG: KASAN: slab-out-of-bounds in __d_lookup_rcu+0x350/0x400 > [ 8.490664] Read of size 8 at addr ffff8009336e2a30 by task init/1 I see this as well, I'm looking into it. It seems that __no_sanitize_address is not defined for clang (defining it doesn't help though, so the issue might be deeper). ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: arm64 kvm built with clang doesn't boot 2018-03-16 14:31 ` Mark Rutland 2018-03-16 14:55 ` Andrey Konovalov @ 2018-04-12 17:35 ` Andrey Konovalov 1 sibling, 0 replies; 14+ messages in thread From: Andrey Konovalov @ 2018-04-12 17:35 UTC (permalink / raw) To: Mark Rutland Cc: Nick Desaulniers, Stephen Hines, Greg Hackmann, Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon, Linux ARM, kvmarm, LKML, kernel-dynamic-tools On Fri, Mar 16, 2018 at 3:31 PM, Mark Rutland <mark.rutland@arm.com> wrote: > On Fri, Mar 16, 2018 at 02:13:14PM +0000, Mark Rutland wrote: >> On Fri, Mar 16, 2018 at 02:49:00PM +0100, Andrey Konovalov wrote: >> > Hi! >> >> Hi, >> >> > I've recently tried to boot clang built kernel on real hardware >> > (Odroid C2 board) instead of using a VM. The issue that I stumbled >> > upon is that arm64 kvm built with clang doesn't boot. >> > >> > Adding -fno-jump-tables compiler flag to arch/arm64/kvm/* helps. There >> > was a patch some time ago that did exactly that >> > (https://patchwork.kernel.org/patch/10060381/), but it wasn't accepted >> > AFAICT (see the discussion on that thread). >> > >> > What would be the best way to get this fixed? >> >> I think that patch is our best bet currently, but to save ourselves pain >> in future it would be *really* nice if GCC and clang could provide an >> option line -fno-absolute-addressing that would implicitly disable any >> feature that would generate an absolute address as jump tables do. >> >> > I've also had to disable CONFIG_JUMP_LABEL to get the kernel boot >> > (even without kvm enabled), but that might be a different (though >> > related) issue. >> >> With v4.15 (and clang 5.0.0), I did not have to disable jump labels to >> get a kernel booting on a Juno platform, though I did have to pass >> -fno-jump-tables to the hyp code. > > FWIW, with that same compiler and patch applied atop of v4.16-rc4, and > some bodges around clang not liking the rX register naming in the SMCCC > code, I get a kernel that boots on my Juno, though I immediately hit a > KASAN splat: > > [ 8.476766] ================================================================== > [ 8.483990] BUG: KASAN: slab-out-of-bounds in __d_lookup_rcu+0x350/0x400 > [ 8.490664] Read of size 8 at addr ffff8009336e2a30 by task init/1 Hi Mark! Just FYI, this should be fixed with https://reviews.llvm.org/D44981 + https://patchwork.kernel.org/patch/10339103/ Thanks! ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: arm64 kvm built with clang doesn't boot 2018-03-16 14:13 ` Mark Rutland 2018-03-16 14:31 ` Mark Rutland @ 2018-03-16 14:50 ` Andrey Konovalov 1 sibling, 0 replies; 14+ messages in thread From: Andrey Konovalov @ 2018-03-16 14:50 UTC (permalink / raw) To: Mark Rutland Cc: Nick Desaulniers, Stephen Hines, Greg Hackmann, Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon, Linux ARM, kvmarm, LKML, kernel-dynamic-tools On Fri, Mar 16, 2018 at 3:13 PM, Mark Rutland <mark.rutland@arm.com> wrote: > I think that patch is our best bet currently, but to save ourselves pain > in future it would be *really* nice if GCC and clang could provide an > option line -fno-absolute-addressing that would implicitly disable any > feature that would generate an absolute address as jump tables do. > Let me know if you want me to mail that patch again. Perhaps Nick can comment on whether something like -fno-absolute-addressing would be feasible in clang. Although even if it gets implemented, it won't fix the already released clang versions. > With v4.15 (and clang 5.0.0), I did not have to disable jump labels to > get a kernel booting on a Juno platform, though I did have to pass > -fno-jump-tables to the hyp code. > > Which kernel version and clang version are you using? I've rechecked and I think I was wrong here. I disabled COFNIG_JUMP_LABEL while trying to get the kernel booting before I added the kvm flags. It seems it's not needed after all. But just for the reference, I'm using 4.16-rc4 with a patch to fix SMCCC issues that you mentioned. As for clang, I'm using LLVM revision 325711 (a couple of weeks old). ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: arm64 kvm built with clang doesn't boot 2018-03-16 13:49 arm64 kvm built with clang doesn't boot Andrey Konovalov 2018-03-16 14:13 ` Mark Rutland @ 2018-03-16 14:13 ` Marc Zyngier 2018-03-16 14:53 ` Andrey Konovalov 1 sibling, 1 reply; 14+ messages in thread From: Marc Zyngier @ 2018-03-16 14:13 UTC (permalink / raw) To: Andrey Konovalov, Nick Desaulniers, Stephen Hines, Greg Hackmann, Christoffer Dall, Catalin Marinas, Will Deacon, Linux ARM, kvmarm, LKML, Mark Rutland Cc: kernel-dynamic-tools Hi Andrey, On 16/03/18 13:49, Andrey Konovalov wrote: > Hi! > > I've recently tried to boot clang built kernel on real hardware > (Odroid C2 board) instead of using a VM. The issue that I stumbled > upon is that arm64 kvm built with clang doesn't boot. > > Adding -fno-jump-tables compiler flag to arch/arm64/kvm/* helps. There > was a patch some time ago that did exactly that > (https://patchwork.kernel.org/patch/10060381/), but it wasn't accepted > AFAICT (see the discussion on that thread). I wasn't aware of that discussion, but this is indeed quite annoying. Note that you should be able to restrict this to arch/arm64/kvm/hyp/* and virt/kvm/arm/hyp/*. > What would be the best way to get this fixed? Ideally, I'd like to see is a way to stick to PC-relative addressing within a compilation unit. > I've also had to disable CONFIG_JUMP_LABEL to get the kernel boot > (even without kvm enabled), but that might be a different (though > related) issue. That's quite bizarre. Does clang has the equivalent of "asm goto"? Or do you rely on reading a variable to decide whether or not to branch? Thanks, M. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: arm64 kvm built with clang doesn't boot 2018-03-16 14:13 ` Marc Zyngier @ 2018-03-16 14:53 ` Andrey Konovalov 2018-03-16 15:00 ` Marc Zyngier 0 siblings, 1 reply; 14+ messages in thread From: Andrey Konovalov @ 2018-03-16 14:53 UTC (permalink / raw) To: Marc Zyngier Cc: Nick Desaulniers, Stephen Hines, Greg Hackmann, Christoffer Dall, Catalin Marinas, Will Deacon, Linux ARM, kvmarm, LKML, Mark Rutland, kernel-dynamic-tools On Fri, Mar 16, 2018 at 3:13 PM, Marc Zyngier <marc.zyngier@arm.com> wrote: > I wasn't aware of that discussion, but this is indeed quite annoying. > Note that you should be able to restrict this to arch/arm64/kvm/hyp/* > and virt/kvm/arm/hyp/*. That works as well (tried it, the kernel boots). I've also tried compiling without the flag for virt/kvm/arm/hyp/*, it boots as well. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: arm64 kvm built with clang doesn't boot 2018-03-16 14:53 ` Andrey Konovalov @ 2018-03-16 15:00 ` Marc Zyngier 2018-03-16 16:52 ` Nick Desaulniers 0 siblings, 1 reply; 14+ messages in thread From: Marc Zyngier @ 2018-03-16 15:00 UTC (permalink / raw) To: Andrey Konovalov Cc: Nick Desaulniers, Stephen Hines, Greg Hackmann, Christoffer Dall, Catalin Marinas, Will Deacon, Linux ARM, kvmarm, LKML, Mark Rutland, kernel-dynamic-tools On 16/03/18 14:53, Andrey Konovalov wrote: > On Fri, Mar 16, 2018 at 3:13 PM, Marc Zyngier <marc.zyngier@arm.com> wrote: >> I wasn't aware of that discussion, but this is indeed quite annoying. >> Note that you should be able to restrict this to arch/arm64/kvm/hyp/* >> and virt/kvm/arm/hyp/*. > > That works as well (tried it, the kernel boots). I've also tried > compiling without the flag for virt/kvm/arm/hyp/*, it boots as well. That's just luck. Anything in a hyp/ directory has the potential to be executed at EL2, and thus could be generating these jump tables. It could blow up at a later time, once you start running VMs... M. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: arm64 kvm built with clang doesn't boot 2018-03-16 15:00 ` Marc Zyngier @ 2018-03-16 16:52 ` Nick Desaulniers 2018-03-16 17:13 ` Mark Rutland 2018-03-16 17:18 ` Marc Zyngier 0 siblings, 2 replies; 14+ messages in thread From: Nick Desaulniers @ 2018-03-16 16:52 UTC (permalink / raw) To: marc.zyngier Cc: Andrey Konovalov, Stephen Hines, Greg Hackmann, christoffer.dall, Catalin Marinas, Will Deacon, linux-arm-kernel, kvmarm, LKML, Mark Rutland, kernel-dynamic-tools, Sami Tolvanen, takahiro.akashi + Sami (Google), Takahiro (Linaro) Just so I fully understand the problem enough to articulate it, we'd be looking for the compiler to keep the jump tables for speed (I would guess -fno-jump-tables would emit an if-else chain) but only emit relative jumps (not absolute jumps)? > Perhaps Nick can comment on whether something like -fno-absolute-addressing would be feasible in clang. Checked with some of my LLVM friends. They mentioned that this is tricky because you need to move the addresses of the jump table from a data section back into the text section. Looks like LLVM has an interesting method `shouldPutJumpTableInFunctionSection` [0]. Unfortunately, it gets overridden for ELF to always return false. [1] It looks like there's also a flag `no-jump-tables` [2]. Looks like Sami has used this in the past in kvm. [3] It's still probably possible to add this to LLVM, so I can pursue that with LLVM devs. > But just for the reference, I'm using 4.16-rc4 with a patch to fix SMCCC issues that you mentioned. Is this in regards to: commit "arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support"? Has anyone tried to upstream a fix for this? We probably want to be very explicit with register widths here. [0] https://github.com/llvm-mirror/llvm/blob/a5bd54307b1adacb3df297b9b8010979b9afa4d7/lib/Target/TargetLoweringObjectFile.cpp#L280 [1] https://github.com/llvm-mirror/llvm/blob/e7676fec11b02e4b698b5ffc99e1901246a7bf66/lib/CodeGen/TargetLoweringObjectFileImpl.cpp#L494 [2] https://github.com/llvm-mirror/llvm/blob/11f5adb29bf90bc1a40b8bb512afcff4b1ac0f56/lib/Transforms/Utils/SimplifyCFG.cpp#L5233 [3] https://patchwork.kernel.org/patch/10060301/ -- Thanks, ~Nick Desaulniers ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: arm64 kvm built with clang doesn't boot 2018-03-16 16:52 ` Nick Desaulniers @ 2018-03-16 17:13 ` Mark Rutland 2018-03-17 10:19 ` Ard Biesheuvel 2018-03-16 17:18 ` Marc Zyngier 1 sibling, 1 reply; 14+ messages in thread From: Mark Rutland @ 2018-03-16 17:13 UTC (permalink / raw) To: Nick Desaulniers Cc: marc.zyngier, Andrey Konovalov, Stephen Hines, Greg Hackmann, christoffer.dall, Catalin Marinas, Will Deacon, linux-arm-kernel, kvmarm, LKML, kernel-dynamic-tools, Sami Tolvanen, takahiro.akashi On Fri, Mar 16, 2018 at 04:52:08PM +0000, Nick Desaulniers wrote: > + Sami (Google), Takahiro (Linaro) > > Just so I fully understand the problem enough to articulate it, we'd be > looking for the compiler to keep the jump tables for speed (I would guess > -fno-jump-tables would emit an if-else chain) but only emit relative jumps > (not absolute jumps)? Our main concern is that there is no absolute addressing. If that rules out using a relative jump table, that's ok. We want to avoid the fragility of collecting -f-no-* options as future compiler transformations end up introducing absolute addressing. Thanks, Mark. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: arm64 kvm built with clang doesn't boot 2018-03-16 17:13 ` Mark Rutland @ 2018-03-17 10:19 ` Ard Biesheuvel 0 siblings, 0 replies; 14+ messages in thread From: Ard Biesheuvel @ 2018-03-17 10:19 UTC (permalink / raw) To: Mark Rutland, Thomas Garnier Cc: Nick Desaulniers, kernel-dynamic-tools, Sami Tolvanen, Marc Zyngier, Andrey Konovalov, Will Deacon, LKML, Greg Hackmann, AKASHI Takahiro, linux-arm-kernel, Stephen Hines, Catalin Marinas, kvmarm, Christoffer Dall (+ Thomas) On 16 March 2018 at 17:13, Mark Rutland <mark.rutland@arm.com> wrote: > On Fri, Mar 16, 2018 at 04:52:08PM +0000, Nick Desaulniers wrote: >> + Sami (Google), Takahiro (Linaro) >> >> Just so I fully understand the problem enough to articulate it, we'd be >> looking for the compiler to keep the jump tables for speed (I would guess >> -fno-jump-tables would emit an if-else chain) but only emit relative jumps >> (not absolute jumps)? > > Our main concern is that there is no absolute addressing. If that rules > out using a relative jump table, that's ok. > > We want to avoid the fragility of collecting -f-no-* options as future > compiler transformations end up introducing absolute addressing. > This all comes back to the assumptions made by the compiler when building PIC/PIE code, i.e., that symbols should be preemptible and thus all references should be indirected via GOT entries, and that text relocations should be avoided. If we had a way to tell the compiler that these concerns do not apply for us, we could use -fpic/-fpie in the kernel and be done with it. -fvisibility=hidden *almost* gives us what we need, but in practice, only the #pragma variant (#pragma GCC visibility push (hidden)) makes -fpic behave in a sensible way for freestanding builds, and gets rid of absolute references where possible (note that statically initialized pointer variables always involve absolute relocations) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: arm64 kvm built with clang doesn't boot 2018-03-16 16:52 ` Nick Desaulniers 2018-03-16 17:13 ` Mark Rutland @ 2018-03-16 17:18 ` Marc Zyngier 2018-03-19 17:42 ` Nick Desaulniers 1 sibling, 1 reply; 14+ messages in thread From: Marc Zyngier @ 2018-03-16 17:18 UTC (permalink / raw) To: Nick Desaulniers Cc: Andrey Konovalov, Stephen Hines, Greg Hackmann, christoffer.dall, Catalin Marinas, Will Deacon, linux-arm-kernel, kvmarm, LKML, Mark Rutland, Sami Tolvanen, takahiro.akashi On 16/03/18 16:52, Nick Desaulniers wrote: [dropping kernel-dynamic-tools@google.com which keeps bouncing] > Is this in regards to: commit "arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP > hardening support"? Has anyone tried to upstream a fix for this? We > probably want to be very explicit with register widths here. What do you mean? The current code is as strict as it gets, and explicitly tells the compiler to use the right register width, based on the SMC call parameter types. Thanks, M. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: arm64 kvm built with clang doesn't boot 2018-03-16 17:18 ` Marc Zyngier @ 2018-03-19 17:42 ` Nick Desaulniers 0 siblings, 0 replies; 14+ messages in thread From: Nick Desaulniers @ 2018-03-19 17:42 UTC (permalink / raw) To: marc.zyngier Cc: Andrey Konovalov, Stephen Hines, Greg Hackmann, Christoffer Dall, Catalin Marinas, Will Deacon, linux-arm-kernel, kvmarm, LKML, Mark Rutland, Sami Tolvanen, Takahiro Akashi, Robin Murphy, dave.martin, Ard Biesheuvel The thread I was thinking of is: http://lists.infradead.org/pipermail/linux-arm-kernel/2018-March/562953.html which is about b092201e0020614127f495c092e0a12d26a2116e `arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support`. As you mention, that commit uses the correct widths. Andrey had sent me his workaround, which modified some #defines in include/linux/arm-smccc.h, which were added recently in commit f2d3b2e8759a5833df6f022e42df2d581e6d843c `arm/arm64: smccc: Implement SMCCC v1.1 inline primitive`. >>> We probably want to be very explicit with register widths here. So f2d3b2e8759 is the patch I'm referring to. On Fri, Mar 16, 2018 at 10:18 AM Marc Zyngier <marc.zyngier@arm.com> wrote: > On 16/03/18 16:52, Nick Desaulniers wrote: > [dropping kernel-dynamic-tools@google.com which keeps bouncing] > > Is this in regards to: commit "arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP > > hardening support"? Has anyone tried to upstream a fix for this? We > > probably want to be very explicit with register widths here. > What do you mean? The current code is as strict as it gets, and > explicitly tells the compiler to use the right register width, based on > the SMC call parameter types. > Thanks, > M. > -- > Jazz is not dead. It just smells funny... -- Thanks, ~Nick Desaulniers ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2018-04-12 17:35 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-03-16 13:49 arm64 kvm built with clang doesn't boot Andrey Konovalov 2018-03-16 14:13 ` Mark Rutland 2018-03-16 14:31 ` Mark Rutland 2018-03-16 14:55 ` Andrey Konovalov 2018-04-12 17:35 ` Andrey Konovalov 2018-03-16 14:50 ` Andrey Konovalov 2018-03-16 14:13 ` Marc Zyngier 2018-03-16 14:53 ` Andrey Konovalov 2018-03-16 15:00 ` Marc Zyngier 2018-03-16 16:52 ` Nick Desaulniers 2018-03-16 17:13 ` Mark Rutland 2018-03-17 10:19 ` Ard Biesheuvel 2018-03-16 17:18 ` Marc Zyngier 2018-03-19 17:42 ` Nick Desaulniers
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).