From: Marc Zyngier <hidden> Date: 2019-01-09 13:55:07
It recently appeared that the nasty hack we use to call a HYP function
on a non-VHE system has an interesting side effect on VHE: We wrap any
such call into a hypercall, losing any form of type checking between
the caller and the callee.
This isn't a big deal if you can guarantee to write code that is
always 100% correct, but it appears that I'm not you.
In order to restore some sanity, let's use the following property: On
a VHE system, it is always possible to call any function directly as
they live in the same address space. We can thus always emit a direct
call, and use a static key to flip from one to the other. As a bonus,
this also sanitizes !VHE systems as we always generate code for noth
revisions of the architecture.
Marc Zyngier (3):
arm/arm64: KVM: Introduce kvm_call_hyp_ret()
arm64: KVM: Allow for direct call of HYP functions when using VHE
arm64: KVM: Drop VHE-specific HYP call stub
arch/arm/include/asm/kvm_host.h | 3 +++
arch/arm64/include/asm/kvm_host.h | 31 ++++++++++++++++++++++++++++++-
arch/arm64/kvm/debug.c | 2 +-
arch/arm64/kvm/hyp.S | 3 ---
arch/arm64/kvm/hyp/hyp-entry.S | 12 ------------
virt/kvm/arm/arm.c | 2 +-
virt/kvm/arm/vgic/vgic-v3.c | 4 ++--
7 files changed, 37 insertions(+), 20 deletions(-)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Marc Zyngier <hidden> Date: 2019-01-09 13:55:16
Until now, we haven't differentiated between HYP calls that
have a return value and those who don't. As we're about to
change this, introduce kvm_call_hyp_ret(), and change all
call sites that actually make use of a return value.
Signed-off-by: Marc Zyngier <redacted>
---
arch/arm/include/asm/kvm_host.h | 3 +++
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/kvm/debug.c | 2 +-
virt/kvm/arm/arm.c | 2 +-
virt/kvm/arm/vgic/vgic-v3.c | 4 ++--
5 files changed, 8 insertions(+), 4 deletions(-)
From: Marc Zyngier <hidden> Date: 2019-01-09 13:55:32
We now call VHE code directly, without going through any central
dispatching function. Let's drop that code.
Signed-off-by: Marc Zyngier <redacted>
---
arch/arm64/kvm/hyp.S | 3 ---
arch/arm64/kvm/hyp/hyp-entry.S | 12 ------------
2 files changed, 15 deletions(-)
@@ -43,18 +43,6 @@ldrlr,[sp],#16.endm-ENTRY(__vhe_hyp_call)-do_el2_call-/*-*Weusedtorelyonhavinganexceptionreturntoget-*animplicitisb.IntheE2Hcase,wedon't have it anymore.-*ratherthanchangingalltheleaffunctions,justdoithere-*beforereturningtotherestofthekernel.-*/-isb-ret-ENDPROC(__vhe_hyp_call)-el1_sync://GuesttrappedintoEL2mrsx0,esr_el2
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Marc Zyngier <hidden> Date: 2019-01-09 13:55:44
When running VHE, there is no need to jump via some stub to perform
a "HYP" function call, as there is a single address space.
Let's thus change kvm_call_hyp() and co to perform a direct call
in this case. Although this results in a bit of code expansion,
it allows the compiler to check for type compatibility, something
that we are missing so far.
Signed-off-by: Marc Zyngier <redacted>
---
arch/arm64/include/asm/kvm_host.h | 32 +++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
From: Andrew Murray <hidden> Date: 2019-01-09 14:24:15
On Wed, Jan 09, 2019 at 01:54:34PM +0000, Marc Zyngier wrote:
quoted hunk
When running VHE, there is no need to jump via some stub to perform
a "HYP" function call, as there is a single address space.
Let's thus change kvm_call_hyp() and co to perform a direct call
in this case. Although this results in a bit of code expansion,
it allows the compiler to check for type compatibility, something
that we are missing so far.
Signed-off-by: Marc Zyngier <redacted>
---
arch/arm64/include/asm/kvm_host.h | 32 +++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
__kvm_get_mdcr_el2 and __kvm_vcpu_run_nvhe don't return u64 type, they
return a smaller type. I guess any issues would be picked up when compiling,
but should the name of the macro be clearer as to the assumptions it makes?
Or perhaps take an argument which is the type of ret?
Andrew Murray
From: Marc Zyngier <hidden> Date: 2019-01-09 14:45:36
Hi Andrew,
On 09/01/2019 14:24, Andrew Murray wrote:
On Wed, Jan 09, 2019 at 01:54:34PM +0000, Marc Zyngier wrote:
quoted
When running VHE, there is no need to jump via some stub to perform
a "HYP" function call, as there is a single address space.
Let's thus change kvm_call_hyp() and co to perform a direct call
in this case. Although this results in a bit of code expansion,
it allows the compiler to check for type compatibility, something
that we are missing so far.
Signed-off-by: Marc Zyngier <redacted>
---
arch/arm64/include/asm/kvm_host.h | 32 +++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
__kvm_get_mdcr_el2 and __kvm_vcpu_run_nvhe don't return u64 type, they
return a smaller type. I guess any issues would be picked up when compiling,
but should the name of the macro be clearer as to the assumptions it makes?
Or perhaps take an argument which is the type of ret?
kvm_call_hyp has always returned a u64, so no semantic has changed here.
Otherwise, your suggestion of specifying a return type is interesting,
but it also gives the programmer another chance to shoot itself in the
foot by not providing the return type corresponding to the function that
is called.
Unless we can extract the return type by pure magic, I'm not sure we
gain much.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Andrew,
On 09/01/2019 14:24, Andrew Murray wrote:
quoted
On Wed, Jan 09, 2019 at 01:54:34PM +0000, Marc Zyngier wrote:
quoted
When running VHE, there is no need to jump via some stub to perform
a "HYP" function call, as there is a single address space.
Let's thus change kvm_call_hyp() and co to perform a direct call
in this case. Although this results in a bit of code expansion,
it allows the compiler to check for type compatibility, something
that we are missing so far.
Signed-off-by: Marc Zyngier <redacted>
---
arch/arm64/include/asm/kvm_host.h | 32 +++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
__kvm_get_mdcr_el2 and __kvm_vcpu_run_nvhe don't return u64 type, they
return a smaller type. I guess any issues would be picked up when compiling,
but should the name of the macro be clearer as to the assumptions it makes?
Or perhaps take an argument which is the type of ret?
kvm_call_hyp has always returned a u64, so no semantic has changed here.
Otherwise, your suggestion of specifying a return type is interesting,
but it also gives the programmer another chance to shoot itself in the
foot by not providing the return type corresponding to the function that
is called.
Unless we can extract the return type by pure magic, I'm not sure we
gain much.
Would the following work?
typeof(f(__VA_ARGS__)) ret;
If typeof works anything like sizeof, I'd expect it would evaluate stuff
passed as argument and we'd have the return type of the function.
Cheers,
--
Julien Thierry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Andrew,
On 09/01/2019 14:24, Andrew Murray wrote:
quoted
On Wed, Jan 09, 2019 at 01:54:34PM +0000, Marc Zyngier wrote:
quoted
When running VHE, there is no need to jump via some stub to perform
a "HYP" function call, as there is a single address space.
Let's thus change kvm_call_hyp() and co to perform a direct call
in this case. Although this results in a bit of code expansion,
it allows the compiler to check for type compatibility, something
that we are missing so far.
Signed-off-by: Marc Zyngier <redacted>
---
arch/arm64/include/asm/kvm_host.h | 32 +++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
__kvm_get_mdcr_el2 and __kvm_vcpu_run_nvhe don't return u64 type, they
return a smaller type. I guess any issues would be picked up when compiling,
but should the name of the macro be clearer as to the assumptions it makes?
Or perhaps take an argument which is the type of ret?
kvm_call_hyp has always returned a u64, so no semantic has changed here.
Otherwise, your suggestion of specifying a return type is interesting,
but it also gives the programmer another chance to shoot itself in the
foot by not providing the return type corresponding to the function that
is called.
Unless we can extract the return type by pure magic, I'm not sure we
gain much.
Would the following work?
typeof(f(__VA_ARGS__)) ret;
If typeof works anything like sizeof, I'd expect it would evaluate stuff
it wouldn't*
passed as argument and we'd have the return type of the function.
Cheers,
From: Marc Zyngier <hidden> Date: 2019-01-09 16:02:06
On 09/01/2019 14:51, Julien Thierry wrote:
On 09/01/2019 14:45, Marc Zyngier wrote:
quoted
Hi Andrew,
On 09/01/2019 14:24, Andrew Murray wrote:
quoted
On Wed, Jan 09, 2019 at 01:54:34PM +0000, Marc Zyngier wrote:
quoted
When running VHE, there is no need to jump via some stub to perform
a "HYP" function call, as there is a single address space.
Let's thus change kvm_call_hyp() and co to perform a direct call
in this case. Although this results in a bit of code expansion,
it allows the compiler to check for type compatibility, something
that we are missing so far.
Signed-off-by: Marc Zyngier <redacted>
---
arch/arm64/include/asm/kvm_host.h | 32 +++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
__kvm_get_mdcr_el2 and __kvm_vcpu_run_nvhe don't return u64 type, they
return a smaller type. I guess any issues would be picked up when compiling,
but should the name of the macro be clearer as to the assumptions it makes?
Or perhaps take an argument which is the type of ret?
kvm_call_hyp has always returned a u64, so no semantic has changed here.
Otherwise, your suggestion of specifying a return type is interesting,
but it also gives the programmer another chance to shoot itself in the
foot by not providing the return type corresponding to the function that
is called.
Unless we can extract the return type by pure magic, I'm not sure we
gain much.
Would the following work?
typeof(f(__VA_ARGS__)) ret;
If typeof works anything like sizeof, I'd expect it would evaluate stuff
passed as argument and we'd have the return type of the function.
And it actually works! Thanks for the awful tip! ;-)
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andrew Murray <hidden> Date: 2019-01-09 16:04:12
On Wed, Jan 09, 2019 at 04:01:56PM +0000, Marc Zyngier wrote:
On 09/01/2019 14:51, Julien Thierry wrote:
quoted
On 09/01/2019 14:45, Marc Zyngier wrote:
quoted
Hi Andrew,
On 09/01/2019 14:24, Andrew Murray wrote:
quoted
On Wed, Jan 09, 2019 at 01:54:34PM +0000, Marc Zyngier wrote:
quoted
When running VHE, there is no need to jump via some stub to perform
a "HYP" function call, as there is a single address space.
Let's thus change kvm_call_hyp() and co to perform a direct call
in this case. Although this results in a bit of code expansion,
it allows the compiler to check for type compatibility, something
that we are missing so far.
Signed-off-by: Marc Zyngier <redacted>
---
arch/arm64/include/asm/kvm_host.h | 32 +++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
__kvm_get_mdcr_el2 and __kvm_vcpu_run_nvhe don't return u64 type, they
return a smaller type. I guess any issues would be picked up when compiling,
but should the name of the macro be clearer as to the assumptions it makes?
Or perhaps take an argument which is the type of ret?
kvm_call_hyp has always returned a u64, so no semantic has changed here.
Ah I missed that!
quoted
quoted
Otherwise, your suggestion of specifying a return type is interesting,
but it also gives the programmer another chance to shoot itself in the
foot by not providing the return type corresponding to the function that
is called.
Unless we can extract the return type by pure magic, I'm not sure we
gain much.
Would the following work?
typeof(f(__VA_ARGS__)) ret;
If typeof works anything like sizeof, I'd expect it would evaluate stuff
passed as argument and we'd have the return type of the function.
And it actually works! Thanks for the awful tip! ;-)
From: Andrew Murray <hidden> Date: 2019-01-09 14:11:47
On Wed, Jan 09, 2019 at 01:54:32PM +0000, Marc Zyngier wrote:
It recently appeared that the nasty hack we use to call a HYP function
on a non-VHE system has an interesting side effect on VHE: We wrap any
such call into a hypercall, losing any form of type checking between
the caller and the callee.
This isn't a big deal if you can guarantee to write code that is
always 100% correct, but it appears that I'm not you.
In order to restore some sanity, let's use the following property: On
a VHE system, it is always possible to call any function directly as
they live in the same address space. We can thus always emit a direct
call, and use a static key to flip from one to the other. As a bonus,
this also sanitizes !VHE systems as we always generate code for noth
s/noth/both/g
Andrew Murray
revisions of the architecture.
Marc Zyngier (3):
arm/arm64: KVM: Introduce kvm_call_hyp_ret()
arm64: KVM: Allow for direct call of HYP functions when using VHE
arm64: KVM: Drop VHE-specific HYP call stub
arch/arm/include/asm/kvm_host.h | 3 +++
arch/arm64/include/asm/kvm_host.h | 31 ++++++++++++++++++++++++++++++-
arch/arm64/kvm/debug.c | 2 +-
arch/arm64/kvm/hyp.S | 3 ---
arch/arm64/kvm/hyp/hyp-entry.S | 12 ------------
virt/kvm/arm/arm.c | 2 +-
virt/kvm/arm/vgic/vgic-v3.c | 4 ++--
7 files changed, 37 insertions(+), 20 deletions(-)
--
2.20.1
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm