* arm64 kvm built with clang doesn't boot
@ 2018-03-16 13:49 ` Andrey Konovalov
0 siblings, 0 replies; 28+ 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] 28+ messages in thread
* arm64 kvm built with clang doesn't boot
@ 2018-03-16 13:49 ` Andrey Konovalov
0 siblings, 0 replies; 28+ messages in thread
From: Andrey Konovalov @ 2018-03-16 13:49 UTC (permalink / raw)
To: linux-arm-kernel
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] 28+ messages in thread
* Re: arm64 kvm built with clang doesn't boot
2018-03-16 13:49 ` Andrey Konovalov
@ 2018-03-16 14:13 ` Mark Rutland
-1 siblings, 0 replies; 28+ 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] 28+ messages in thread
* arm64 kvm built with clang doesn't boot
@ 2018-03-16 14:13 ` Mark Rutland
0 siblings, 0 replies; 28+ messages in thread
From: Mark Rutland @ 2018-03-16 14:13 UTC (permalink / raw)
To: linux-arm-kernel
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] 28+ messages in thread
* Re: arm64 kvm built with clang doesn't boot
2018-03-16 13:49 ` Andrey Konovalov
@ 2018-03-16 14:13 ` Marc Zyngier
-1 siblings, 0 replies; 28+ 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] 28+ messages in thread
* arm64 kvm built with clang doesn't boot
@ 2018-03-16 14:13 ` Marc Zyngier
0 siblings, 0 replies; 28+ messages in thread
From: Marc Zyngier @ 2018-03-16 14:13 UTC (permalink / raw)
To: linux-arm-kernel
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] 28+ 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
-1 siblings, 0 replies; 28+ 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] 28+ messages in thread
* arm64 kvm built with clang doesn't boot
@ 2018-03-16 14:31 ` Mark Rutland
0 siblings, 0 replies; 28+ messages in thread
From: Mark Rutland @ 2018-03-16 14:31 UTC (permalink / raw)
To: linux-arm-kernel
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] 28+ messages in thread
* Re: arm64 kvm built with clang doesn't boot
2018-03-16 14:13 ` Mark Rutland
@ 2018-03-16 14:50 ` Andrey Konovalov
-1 siblings, 0 replies; 28+ 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] 28+ messages in thread
* arm64 kvm built with clang doesn't boot
@ 2018-03-16 14:50 ` Andrey Konovalov
0 siblings, 0 replies; 28+ messages in thread
From: Andrey Konovalov @ 2018-03-16 14:50 UTC (permalink / raw)
To: linux-arm-kernel
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] 28+ 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
-1 siblings, 0 replies; 28+ 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] 28+ messages in thread
* arm64 kvm built with clang doesn't boot
@ 2018-03-16 14:53 ` Andrey Konovalov
0 siblings, 0 replies; 28+ messages in thread
From: Andrey Konovalov @ 2018-03-16 14:53 UTC (permalink / raw)
To: linux-arm-kernel
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] 28+ 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
-1 siblings, 0 replies; 28+ 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] 28+ messages in thread
* arm64 kvm built with clang doesn't boot
@ 2018-03-16 14:55 ` Andrey Konovalov
0 siblings, 0 replies; 28+ messages in thread
From: Andrey Konovalov @ 2018-03-16 14:55 UTC (permalink / raw)
To: linux-arm-kernel
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] 28+ 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
-1 siblings, 0 replies; 28+ 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] 28+ messages in thread
* arm64 kvm built with clang doesn't boot
@ 2018-03-16 15:00 ` Marc Zyngier
0 siblings, 0 replies; 28+ messages in thread
From: Marc Zyngier @ 2018-03-16 15:00 UTC (permalink / raw)
To: linux-arm-kernel
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] 28+ 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
-1 siblings, 0 replies; 28+ 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] 28+ messages in thread
* arm64 kvm built with clang doesn't boot
@ 2018-03-16 16:52 ` Nick Desaulniers
0 siblings, 0 replies; 28+ messages in thread
From: Nick Desaulniers @ 2018-03-16 16:52 UTC (permalink / raw)
To: linux-arm-kernel
+ 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] 28+ 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
-1 siblings, 0 replies; 28+ 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] 28+ messages in thread
* arm64 kvm built with clang doesn't boot
@ 2018-03-16 17:13 ` Mark Rutland
0 siblings, 0 replies; 28+ messages in thread
From: Mark Rutland @ 2018-03-16 17:13 UTC (permalink / raw)
To: linux-arm-kernel
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] 28+ messages in thread
* Re: arm64 kvm built with clang doesn't boot
2018-03-16 16:52 ` Nick Desaulniers
@ 2018-03-16 17:18 ` Marc Zyngier
-1 siblings, 0 replies; 28+ 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] 28+ messages in thread
* arm64 kvm built with clang doesn't boot
@ 2018-03-16 17:18 ` Marc Zyngier
0 siblings, 0 replies; 28+ messages in thread
From: Marc Zyngier @ 2018-03-16 17:18 UTC (permalink / raw)
To: linux-arm-kernel
On 16/03/18 16:52, Nick Desaulniers wrote:
[dropping kernel-dynamic-tools at 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] 28+ 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
-1 siblings, 0 replies; 28+ 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] 28+ messages in thread
* arm64 kvm built with clang doesn't boot
@ 2018-03-17 10:19 ` Ard Biesheuvel
0 siblings, 0 replies; 28+ messages in thread
From: Ard Biesheuvel @ 2018-03-17 10:19 UTC (permalink / raw)
To: linux-arm-kernel
(+ 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] 28+ 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
-1 siblings, 0 replies; 28+ 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] 28+ messages in thread
* arm64 kvm built with clang doesn't boot
@ 2018-03-19 17:42 ` Nick Desaulniers
0 siblings, 0 replies; 28+ messages in thread
From: Nick Desaulniers @ 2018-03-19 17:42 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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] 28+ messages in thread
* Re: arm64 kvm built with clang doesn't boot
2018-03-16 14:31 ` Mark Rutland
@ 2018-04-12 17:35 ` Andrey Konovalov
-1 siblings, 0 replies; 28+ 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] 28+ messages in thread
* arm64 kvm built with clang doesn't boot
@ 2018-04-12 17:35 ` Andrey Konovalov
0 siblings, 0 replies; 28+ messages in thread
From: Andrey Konovalov @ 2018-04-12 17:35 UTC (permalink / raw)
To: linux-arm-kernel
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] 28+ messages in thread
end of thread, other threads:[~2018-04-12 17:35 UTC | newest]
Thread overview: 28+ 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 13:49 ` Andrey Konovalov
2018-03-16 14:13 ` Mark Rutland
2018-03-16 14:13 ` Mark Rutland
2018-03-16 14:31 ` Mark Rutland
2018-03-16 14:31 ` Mark Rutland
2018-03-16 14:55 ` Andrey Konovalov
2018-03-16 14:55 ` Andrey Konovalov
2018-04-12 17:35 ` Andrey Konovalov
2018-04-12 17:35 ` Andrey Konovalov
2018-03-16 14:50 ` Andrey Konovalov
2018-03-16 14:50 ` Andrey Konovalov
2018-03-16 14:13 ` Marc Zyngier
2018-03-16 14:13 ` Marc Zyngier
2018-03-16 14:53 ` Andrey Konovalov
2018-03-16 14:53 ` Andrey Konovalov
2018-03-16 15:00 ` Marc Zyngier
2018-03-16 15:00 ` Marc Zyngier
2018-03-16 16:52 ` Nick Desaulniers
2018-03-16 16:52 ` Nick Desaulniers
2018-03-16 17:13 ` Mark Rutland
2018-03-16 17:13 ` Mark Rutland
2018-03-17 10:19 ` Ard Biesheuvel
2018-03-17 10:19 ` Ard Biesheuvel
2018-03-16 17:18 ` Marc Zyngier
2018-03-16 17:18 ` Marc Zyngier
2018-03-19 17:42 ` Nick Desaulniers
2018-03-19 17:42 ` Nick Desaulniers
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.