All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] ARM: KVM: Fix idmap stub entry when running Thumb-2 code
@ 2017-04-20 15:02 ` Marc Zyngier
  0 siblings, 0 replies; 4+ messages in thread
From: Marc Zyngier @ 2017-04-20 15:02 UTC (permalink / raw)
  To: Christoffer Dall; +Cc: kvmarm, kvm, linux-arm-kernel

When entering the hyp stub implemented in the idmap, we try to
be mindful of the fact that we could be running a Thumb-2 kernel
by adding 1 to the address we compute. Unfortunately, the assembler
also knows about this trick, and has already generated an address
that has bit 0 set in the litteral pool.

Our superfluous correction ends up confusing the CPU entierely,
as we now branch to the stub in ARM mode instead of Thumb, and on
a possibly unaligned address for good measure. From that point,
nothing really good happens.

The obvious fix in to remove this stupid target PC correction.

Fixes: 6bebcecb6c5b ("ARM: KVM: Allow the main HYP code to use the init hyp stub implementation")
Reported-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
 arch/arm/kvm/hyp/hyp-entry.S | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/kvm/hyp/hyp-entry.S b/arch/arm/kvm/hyp/hyp-entry.S
index a35baa81fd23..95a2faefc070 100644
--- a/arch/arm/kvm/hyp/hyp-entry.S
+++ b/arch/arm/kvm/hyp/hyp-entry.S
@@ -144,7 +144,6 @@ hyp_hvc:
 	ldr	r1, [r1]
 	ldr	ip, =__kvm_handle_stub_hvc
 	sub	ip, ip, r1
-THUMB(	add	ip, ip, #1)
 	pop	{r1}
 
 	bx	ip
-- 
2.11.0

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* [PATCH] ARM: KVM: Fix idmap stub entry when running Thumb-2 code
@ 2017-04-20 15:02 ` Marc Zyngier
  0 siblings, 0 replies; 4+ messages in thread
From: Marc Zyngier @ 2017-04-20 15:02 UTC (permalink / raw)
  To: linux-arm-kernel

When entering the hyp stub implemented in the idmap, we try to
be mindful of the fact that we could be running a Thumb-2 kernel
by adding 1 to the address we compute. Unfortunately, the assembler
also knows about this trick, and has already generated an address
that has bit 0 set in the litteral pool.

Our superfluous correction ends up confusing the CPU entierely,
as we now branch to the stub in ARM mode instead of Thumb, and on
a possibly unaligned address for good measure. From that point,
nothing really good happens.

The obvious fix in to remove this stupid target PC correction.

Fixes: 6bebcecb6c5b ("ARM: KVM: Allow the main HYP code to use the init hyp stub implementation")
Reported-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
 arch/arm/kvm/hyp/hyp-entry.S | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/kvm/hyp/hyp-entry.S b/arch/arm/kvm/hyp/hyp-entry.S
index a35baa81fd23..95a2faefc070 100644
--- a/arch/arm/kvm/hyp/hyp-entry.S
+++ b/arch/arm/kvm/hyp/hyp-entry.S
@@ -144,7 +144,6 @@ hyp_hvc:
 	ldr	r1, [r1]
 	ldr	ip, =__kvm_handle_stub_hvc
 	sub	ip, ip, r1
-THUMB(	add	ip, ip, #1)
 	pop	{r1}
 
 	bx	ip
-- 
2.11.0

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] ARM: KVM: Fix idmap stub entry when running Thumb-2 code
  2017-04-20 15:02 ` Marc Zyngier
@ 2017-04-20 19:02   ` Christoffer Dall
  -1 siblings, 0 replies; 4+ messages in thread
From: Christoffer Dall @ 2017-04-20 19:02 UTC (permalink / raw)
  To: Marc Zyngier; +Cc: linux-arm-kernel, kvmarm, kvm

On Thu, Apr 20, 2017 at 04:02:21PM +0100, Marc Zyngier wrote:
> When entering the hyp stub implemented in the idmap, we try to
> be mindful of the fact that we could be running a Thumb-2 kernel
> by adding 1 to the address we compute. Unfortunately, the assembler
> also knows about this trick, and has already generated an address
> that has bit 0 set in the litteral pool.
> 
> Our superfluous correction ends up confusing the CPU entierely,
> as we now branch to the stub in ARM mode instead of Thumb, and on
> a possibly unaligned address for good measure. From that point,
> nothing really good happens.
> 
> The obvious fix in to remove this stupid target PC correction.
> 
> Fixes: 6bebcecb6c5b ("ARM: KVM: Allow the main HYP code to use the init hyp stub implementation")
> Reported-by: Christoffer Dall <cdall@linaro.org>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

This works, thanks.

Applied to kvmarm/next.
-Christoffer

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [PATCH] ARM: KVM: Fix idmap stub entry when running Thumb-2 code
@ 2017-04-20 19:02   ` Christoffer Dall
  0 siblings, 0 replies; 4+ messages in thread
From: Christoffer Dall @ 2017-04-20 19:02 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Apr 20, 2017 at 04:02:21PM +0100, Marc Zyngier wrote:
> When entering the hyp stub implemented in the idmap, we try to
> be mindful of the fact that we could be running a Thumb-2 kernel
> by adding 1 to the address we compute. Unfortunately, the assembler
> also knows about this trick, and has already generated an address
> that has bit 0 set in the litteral pool.
> 
> Our superfluous correction ends up confusing the CPU entierely,
> as we now branch to the stub in ARM mode instead of Thumb, and on
> a possibly unaligned address for good measure. From that point,
> nothing really good happens.
> 
> The obvious fix in to remove this stupid target PC correction.
> 
> Fixes: 6bebcecb6c5b ("ARM: KVM: Allow the main HYP code to use the init hyp stub implementation")
> Reported-by: Christoffer Dall <cdall@linaro.org>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

This works, thanks.

Applied to kvmarm/next.
-Christoffer

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2017-04-20 19:02 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-20 15:02 [PATCH] ARM: KVM: Fix idmap stub entry when running Thumb-2 code Marc Zyngier
2017-04-20 15:02 ` Marc Zyngier
2017-04-20 19:02 ` Christoffer Dall
2017-04-20 19:02   ` Christoffer Dall

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.