From: Marc Zyngier <maz@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will@kernel.org>,
kernel-team@android.com, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org
Subject: Re: [PATCH 03/11] KVM: arm64: Make kvm_skip_instr() and co private to HYP
Date: Tue, 27 Oct 2020 16:17:31 +0000 [thread overview]
Message-ID: <bde9a2a8233f3d7e96751ad3640b11b7@kernel.org> (raw)
In-Reply-To: <20201026140435.GE12454@C02TD0UTHF1T.local>
On 2020-10-26 14:04, Mark Rutland wrote:
> On Mon, Oct 26, 2020 at 01:34:42PM +0000, Marc Zyngier wrote:
>> In an effort to remove the vcpu PC manipulations from EL1 on nVHE
>> systems, move kvm_skip_instr() to be HYP-specific. EL1's intent
>> to increment PC post emulation is now signalled via a flag in the
>> vcpu structure.
>>
>> Signed-off-by: Marc Zyngier <maz@kernel.org>
>
> [...]
>
>> +/*
>> + * Adjust the guest PC on entry, depending on flags provided by EL1
>> + * for the purpose of emulation (MMIO, sysreg).
>> + */
>> +static inline void __adjust_pc(struct kvm_vcpu *vcpu)
>> +{
>> + if (vcpu->arch.flags & KVM_ARM64_INCREMENT_PC) {
>> + kvm_skip_instr(vcpu);
>> + vcpu->arch.flags &= ~KVM_ARM64_INCREMENT_PC;
>> + }
>> +}
>
> What's your plan for restricting *when* EL1 can ask for the PC to be
> adjusted?
>
> I'm assuming that either:
>
> 1. You have EL2 sanity-check all responses from EL1 are permitted for
> the current state. e.g. if EL1 asks to increment the PC, EL2 must
> check that that was a sane response for the current state.
>
> 2. You raise the level of abstraction at the EL2/EL1 boundary, such
> that
> EL2 simply knows. e.g. if emulating a memory access, EL1 can either
> provide the response or signal an abort, but doesn't choose to
> manipulate the PC as EL2 will infer the right thing to do.
>
> I know that either are tricky in practice, so I'm curious what your
> view
> is. Generally option #2 is easier to fortify, but I guess we might have
> to do #1 since we also have to support unprotected VMs?
To be honest, I'm still in two minds about it, which is why I have
gone with this "middle of the road" option (moving the PC update
to EL2, but leave the control at EL1).
I guess the answer is "it depends". MMIO is easy to put in the #2 model,
while things like WFI/WFE really need #1. sysregs are yet another can of
worm.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will@kernel.org>,
kernel-team@android.com, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org
Subject: Re: [PATCH 03/11] KVM: arm64: Make kvm_skip_instr() and co private to HYP
Date: Tue, 27 Oct 2020 16:17:31 +0000 [thread overview]
Message-ID: <bde9a2a8233f3d7e96751ad3640b11b7@kernel.org> (raw)
In-Reply-To: <20201026140435.GE12454@C02TD0UTHF1T.local>
On 2020-10-26 14:04, Mark Rutland wrote:
> On Mon, Oct 26, 2020 at 01:34:42PM +0000, Marc Zyngier wrote:
>> In an effort to remove the vcpu PC manipulations from EL1 on nVHE
>> systems, move kvm_skip_instr() to be HYP-specific. EL1's intent
>> to increment PC post emulation is now signalled via a flag in the
>> vcpu structure.
>>
>> Signed-off-by: Marc Zyngier <maz@kernel.org>
>
> [...]
>
>> +/*
>> + * Adjust the guest PC on entry, depending on flags provided by EL1
>> + * for the purpose of emulation (MMIO, sysreg).
>> + */
>> +static inline void __adjust_pc(struct kvm_vcpu *vcpu)
>> +{
>> + if (vcpu->arch.flags & KVM_ARM64_INCREMENT_PC) {
>> + kvm_skip_instr(vcpu);
>> + vcpu->arch.flags &= ~KVM_ARM64_INCREMENT_PC;
>> + }
>> +}
>
> What's your plan for restricting *when* EL1 can ask for the PC to be
> adjusted?
>
> I'm assuming that either:
>
> 1. You have EL2 sanity-check all responses from EL1 are permitted for
> the current state. e.g. if EL1 asks to increment the PC, EL2 must
> check that that was a sane response for the current state.
>
> 2. You raise the level of abstraction at the EL2/EL1 boundary, such
> that
> EL2 simply knows. e.g. if emulating a memory access, EL1 can either
> provide the response or signal an abort, but doesn't choose to
> manipulate the PC as EL2 will infer the right thing to do.
>
> I know that either are tricky in practice, so I'm curious what your
> view
> is. Generally option #2 is easier to fortify, but I guess we might have
> to do #1 since we also have to support unprotected VMs?
To be honest, I'm still in two minds about it, which is why I have
gone with this "middle of the road" option (moving the PC update
to EL2, but leave the control at EL1).
I guess the answer is "it depends". MMIO is easy to put in the #2 model,
while things like WFI/WFE really need #1. sysregs are yet another can of
worm.
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
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
kernel-team@android.com, Will Deacon <will@kernel.org>
Subject: Re: [PATCH 03/11] KVM: arm64: Make kvm_skip_instr() and co private to HYP
Date: Tue, 27 Oct 2020 16:17:31 +0000 [thread overview]
Message-ID: <bde9a2a8233f3d7e96751ad3640b11b7@kernel.org> (raw)
In-Reply-To: <20201026140435.GE12454@C02TD0UTHF1T.local>
On 2020-10-26 14:04, Mark Rutland wrote:
> On Mon, Oct 26, 2020 at 01:34:42PM +0000, Marc Zyngier wrote:
>> In an effort to remove the vcpu PC manipulations from EL1 on nVHE
>> systems, move kvm_skip_instr() to be HYP-specific. EL1's intent
>> to increment PC post emulation is now signalled via a flag in the
>> vcpu structure.
>>
>> Signed-off-by: Marc Zyngier <maz@kernel.org>
>
> [...]
>
>> +/*
>> + * Adjust the guest PC on entry, depending on flags provided by EL1
>> + * for the purpose of emulation (MMIO, sysreg).
>> + */
>> +static inline void __adjust_pc(struct kvm_vcpu *vcpu)
>> +{
>> + if (vcpu->arch.flags & KVM_ARM64_INCREMENT_PC) {
>> + kvm_skip_instr(vcpu);
>> + vcpu->arch.flags &= ~KVM_ARM64_INCREMENT_PC;
>> + }
>> +}
>
> What's your plan for restricting *when* EL1 can ask for the PC to be
> adjusted?
>
> I'm assuming that either:
>
> 1. You have EL2 sanity-check all responses from EL1 are permitted for
> the current state. e.g. if EL1 asks to increment the PC, EL2 must
> check that that was a sane response for the current state.
>
> 2. You raise the level of abstraction at the EL2/EL1 boundary, such
> that
> EL2 simply knows. e.g. if emulating a memory access, EL1 can either
> provide the response or signal an abort, but doesn't choose to
> manipulate the PC as EL2 will infer the right thing to do.
>
> I know that either are tricky in practice, so I'm curious what your
> view
> is. Generally option #2 is easier to fortify, but I guess we might have
> to do #1 since we also have to support unprotected VMs?
To be honest, I'm still in two minds about it, which is why I have
gone with this "middle of the road" option (moving the PC update
to EL2, but leave the control at EL1).
I guess the answer is "it depends". MMIO is easy to put in the #2 model,
while things like WFI/WFE really need #1. sysregs are yet another can of
worm.
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2020-10-27 16:17 UTC|newest]
Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-26 13:34 [PATCH 00/11] KVM: arm64: Move PC/ELR/SPSR/PSTATE updatess to EL2 Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 13:34 ` [PATCH 01/11] KVM: arm64: Don't adjust PC on SError during SMC trap Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 13:53 ` Mark Rutland
2020-10-26 13:53 ` Mark Rutland
2020-10-26 13:53 ` Mark Rutland
2020-10-26 14:08 ` Marc Zyngier
2020-10-26 14:08 ` Marc Zyngier
2020-10-26 14:08 ` Marc Zyngier
2020-10-26 14:22 ` Mark Rutland
2020-10-26 14:22 ` Mark Rutland
2020-10-26 14:22 ` Mark Rutland
2020-10-26 13:34 ` [PATCH 02/11] KVM: arm64: Move kvm_vcpu_trap_il_is32bit into kvm_skip_instr32() Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 13:55 ` Mark Rutland
2020-10-26 13:55 ` Mark Rutland
2020-10-26 13:55 ` Mark Rutland
2020-10-26 13:34 ` [PATCH 03/11] KVM: arm64: Make kvm_skip_instr() and co private to HYP Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 14:04 ` Mark Rutland
2020-10-26 14:04 ` Mark Rutland
2020-10-26 14:04 ` Mark Rutland
2020-10-27 16:17 ` Marc Zyngier [this message]
2020-10-27 16:17 ` Marc Zyngier
2020-10-27 16:17 ` Marc Zyngier
2020-10-27 10:55 ` Suzuki K Poulose
2020-10-27 10:55 ` Suzuki K Poulose
2020-10-27 10:55 ` Suzuki K Poulose
2020-10-27 11:08 ` Marc Zyngier
2020-10-27 11:08 ` Marc Zyngier
2020-10-27 11:08 ` Marc Zyngier
2020-10-26 13:34 ` [PATCH 04/11] KVM: arm64: Move PC rollback on SError " Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 14:06 ` Mark Rutland
2020-10-26 14:06 ` Mark Rutland
2020-10-26 14:06 ` Mark Rutland
2020-10-27 14:56 ` James Morse
2020-10-27 14:56 ` James Morse
2020-10-27 14:56 ` James Morse
2020-10-27 14:59 ` Marc Zyngier
2020-10-27 14:59 ` Marc Zyngier
2020-10-27 14:59 ` Marc Zyngier
2020-10-26 13:34 ` [PATCH 05/11] KVM: arm64: Move VHE direct sysreg accessors into kvm_host.h Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 14:07 ` Mark Rutland
2020-10-26 14:07 ` Mark Rutland
2020-10-26 14:07 ` Mark Rutland
2020-10-26 13:34 ` [PATCH 06/11] KVM: arm64: Add basic hooks for injecting exceptions from EL2 Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 13:34 ` [PATCH 07/11] KVM: arm64: Inject AArch64 exceptions from HYP Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 14:22 ` Mark Rutland
2020-10-26 14:22 ` Mark Rutland
2020-10-26 14:22 ` Mark Rutland
2020-10-27 16:21 ` Marc Zyngier
2020-10-27 16:21 ` Marc Zyngier
2020-10-27 16:21 ` Marc Zyngier
2020-10-27 17:41 ` James Morse
2020-10-27 17:41 ` James Morse
2020-10-27 17:41 ` James Morse
2020-10-27 18:49 ` Marc Zyngier
2020-10-27 18:49 ` Marc Zyngier
2020-10-27 18:49 ` Marc Zyngier
2020-10-26 13:34 ` [PATCH 08/11] KVM: arm64: Inject AArch32 " Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 14:26 ` Mark Rutland
2020-10-26 14:26 ` Mark Rutland
2020-10-26 14:26 ` Mark Rutland
2020-10-27 17:41 ` James Morse
2020-10-27 17:41 ` James Morse
2020-10-27 17:41 ` James Morse
2020-10-27 19:21 ` Marc Zyngier
2020-10-27 19:21 ` Marc Zyngier
2020-10-27 19:21 ` Marc Zyngier
2020-10-28 19:20 ` James Morse
2020-10-28 19:20 ` James Morse
2020-10-28 19:20 ` James Morse
2020-10-28 20:24 ` Marc Zyngier
2020-10-28 20:24 ` Marc Zyngier
2020-10-28 20:24 ` Marc Zyngier
2020-10-26 13:34 ` [PATCH 09/11] KVM: arm64: Remove SPSR manipulation primitives Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 14:30 ` Mark Rutland
2020-10-26 14:30 ` Mark Rutland
2020-10-26 14:30 ` Mark Rutland
2020-10-26 13:34 ` [PATCH 10/11] KVM: arm64: Consolidate exception injection Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 13:34 ` [PATCH 11/11] KVM: arm64: Get rid of the AArch32 register mapping code Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
2020-10-26 13:34 ` Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bde9a2a8233f3d7e96751ad3640b11b7@kernel.org \
--to=maz@kernel.org \
--cc=kernel-team@android.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.