diff mbox

[v2,06/18] arm64: kvm: use -fno-jump-tables with clang

Message ID 20171115213428.22559-7-samitolvanen@google.com (mailing list archive)
State New, archived
Headers show

Commit Message

Sami Tolvanen Nov. 15, 2017, 9:34 p.m. UTC
Use -fno-jump-tables to make sure clang doesn't generate branches
to EL1 virtual addresses.

Suggested-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/kvm/hyp/Makefile | 4 ++++
 1 file changed, 4 insertions(+)

Comments

Will Deacon Nov. 16, 2017, 11:46 a.m. UTC | #1
On Wed, Nov 15, 2017 at 01:34:16PM -0800, Sami Tolvanen wrote:
> Use -fno-jump-tables to make sure clang doesn't generate branches
> to EL1 virtual addresses.

Can you elaborate a bit more on exactly what you saw failing here, please?
Whilst it's obviously broken to jump to EL1 from EL2 w/o VHE, the commit
message is a bit cryptic.

Will
Sami Tolvanen Nov. 16, 2017, 4:25 p.m. UTC | #2
On Thu, Nov 16, 2017 at 11:46:17AM +0000, Will Deacon wrote:
> Can you elaborate a bit more on exactly what you saw failing here,
> please?

Mark noticed that clang built kernels fail to boot when the kernel
starts at EL2:

  http://lkml.iu.edu/hypermail/linux/kernel/1711.0/02817.html

Turns out starting with LLVM r308050, the compiler decides to use
a jump table in __init_stage2_translation, and generates code that
branches into an EL1 virtual address.

> Whilst it's obviously broken to jump to EL1 from EL2 w/o VHE, the
> commit message is a bit cryptic.

I agree, I'll add a more descriptive commit message for v3.

Sami
Mark Rutland Nov. 20, 2017, 2:41 p.m. UTC | #3
On Wed, Nov 15, 2017 at 01:34:16PM -0800, Sami Tolvanen wrote:
> Use -fno-jump-tables to make sure clang doesn't generate branches
> to EL1 virtual addresses.

Are there any other reasons that clang might generate absolute
references/relocations?

It would be nice if there was the option to disable that more generally,
rather than disabling individual optimizations. Is there any PIC/PIE
option that we could use?

We might need something simnilar for GCC, even if we're not seeing
problems today.

Thanks,
Mark.

> Suggested-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> ---
>  arch/arm64/kvm/hyp/Makefile | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm64/kvm/hyp/Makefile b/arch/arm64/kvm/hyp/Makefile
> index f04400d494b7..19fa1c6b6b69 100644
> --- a/arch/arm64/kvm/hyp/Makefile
> +++ b/arch/arm64/kvm/hyp/Makefile
> @@ -5,6 +5,10 @@
>  
>  ccflags-y += -fno-stack-protector -DDISABLE_BRANCH_PROFILING
>  
> +ifeq ($(cc-name),clang)
> +ccflags-y += -fno-jump-tables
> +endif
> +
>  KVM=../../../../virt/kvm
>  
>  obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v2-sr.o
> -- 
> 2.15.0.448.gf294e3d99a-goog
>
Mark Rutland Nov. 20, 2017, 2:43 p.m. UTC | #4
On Mon, Nov 20, 2017 at 02:41:47PM +0000, Mark Rutland wrote:
> On Wed, Nov 15, 2017 at 01:34:16PM -0800, Sami Tolvanen wrote:
> > Use -fno-jump-tables to make sure clang doesn't generate branches
> > to EL1 virtual addresses.
> 
> Are there any other reasons that clang might generate absolute
> references/relocations?
> 
> It would be nice if there was the option to disable that more generally,
> rather than disabling individual optimizations. Is there any PIC/PIE
> option that we could use?
> 
> We might need something simnilar for GCC, even if we're not seeing
> problems today.

... and likewise for the EFI stub, which needs to be
position-independent much like the hyp code.

Thanks,
Mark.
Ard Biesheuvel Nov. 20, 2017, 2:47 p.m. UTC | #5
On 20 November 2017 at 14:43, Mark Rutland <mark.rutland@arm.com> wrote:
> On Mon, Nov 20, 2017 at 02:41:47PM +0000, Mark Rutland wrote:
>> On Wed, Nov 15, 2017 at 01:34:16PM -0800, Sami Tolvanen wrote:
>> > Use -fno-jump-tables to make sure clang doesn't generate branches
>> > to EL1 virtual addresses.
>>
>> Are there any other reasons that clang might generate absolute
>> references/relocations?
>>
>> It would be nice if there was the option to disable that more generally,
>> rather than disabling individual optimizations. Is there any PIC/PIE
>> option that we could use?
>>
>> We might need something simnilar for GCC, even if we're not seeing
>> problems today.
>
> ... and likewise for the EFI stub, which needs to be
> position-independent much like the hyp code.
>

Actually, we are already using -fpie for the EFI stub, but it is a bit
fiddly because it requires visibility overrides, given that PIC symbol
references are usually indirected via GOT entries. At the time, it
didn't occur to me that the HYP code has similar issues. Of course, in
the EFI stub we already check for ABS64 relocations to make sure that
the resulting code is correct (and /me makes mental note to add
R_AARCH64_GOT_xxx relocations to that as well)
diff mbox

Patch

diff --git a/arch/arm64/kvm/hyp/Makefile b/arch/arm64/kvm/hyp/Makefile
index f04400d494b7..19fa1c6b6b69 100644
--- a/arch/arm64/kvm/hyp/Makefile
+++ b/arch/arm64/kvm/hyp/Makefile
@@ -5,6 +5,10 @@ 
 
 ccflags-y += -fno-stack-protector -DDISABLE_BRANCH_PROFILING
 
+ifeq ($(cc-name),clang)
+ccflags-y += -fno-jump-tables
+endif
+
 KVM=../../../../virt/kvm
 
 obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v2-sr.o