From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 04/12] ARM: KVM: Initial VGIC infrastructure code
Date: Tue, 15 Jan 2013 10:33:30 +0000 [thread overview]
Message-ID: <50F5307A.6000406@arm.com> (raw)
In-Reply-To: <CANM98q+y4GoHmqh-CS+fDnfbDbBQHQOY05urer5DMgy9b1X5ng@mail.gmail.com>
On 14/01/13 21:08, Christoffer Dall wrote:
> On Mon, Jan 14, 2013 at 10:31 AM, Will Deacon <will.deacon@arm.com> wrote:
>> As I mentioned previously, I suspect that this doesn't work with big-endian
>> systems. Whilst that's reasonable for the moment, a comment would be useful
>> for the unlucky soul that decides to do that work in future (or add
>> accessors for mmio->data as I suggested before).
>>
> admittedly this really hurts my brain, but I think there's actually no
> problem with endianness: whatever comes in mmio->data will have native
> endianness and the vgic is always little-endian, so a guest would have
> to make sure to do its own endianness conversion before writing data,
> or did I get this backwards? (some nasty feeling about if the OS is
> compiled in another endianness than the hardware everything may
> break).
>
> Anyhow, I think there's another bug in this code though. Please take a
> look and see if you agree:
>
> commit 3cab2b93a6f6acd3c043e584f23b94ab8f1bbd66
> Author: Christoffer Dall <c.dall@virtualopensystems.com>
> Date: Mon Jan 14 15:55:18 2013 -0500
>
> KVM: ARM: Limit vgic read/writes to load/store length
>
> The vgic read/write operations did not consider ldrb/strb masks, and
> would therefore unintentionally overwrite parts of a register.
>
> Consider for example a store of a single byte to a word-aligned address
> of one of the priority registers, that would cause the 3 most
> significant bytes to be overwritten with zeros.
>
> Cc: Marc Zyniger <marc.zyngier@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>
> diff --git a/arch/arm/kvm/vgic.c b/arch/arm/kvm/vgic.c
> index 25daa07..5c1bcf5 100644
> --- a/arch/arm/kvm/vgic.c
> +++ b/arch/arm/kvm/vgic.c
> @@ -233,6 +233,16 @@ static void vgic_cpu_irq_clear(struct kvm_vcpu
> *vcpu, int irq)
> vcpu->arch.vgic_cpu.pending_shared);
> }
>
> +static u32 mmio_data_read(struct kvm_exit_mmio *mmio, u32 mask)
> +{
> + return *((u32 *)mmio->data) & mask;
> +}
> +
> +static void mmio_data_write(struct kvm_exit_mmio *mmio, u32 mask, u32 value)
> +{
> + *((u32 *)mmio->data) = value & mask;
> +}
> +
> /**
> * vgic_reg_access - access vgic register
> * @mmio: pointer to the data describing the mmio access
> @@ -247,8 +257,8 @@ static void vgic_cpu_irq_clear(struct kvm_vcpu
> *vcpu, int irq)
> static void vgic_reg_access(struct kvm_exit_mmio *mmio, u32 *reg,
> phys_addr_t offset, int mode)
> {
> - int shift = (offset & 3) * 8;
> - u32 mask;
> + int word_offset = (offset & 3) * 8;
> + u32 mask = (1UL << (mmio->len * 8)) - 1;
> u32 regval;
>
> /*
> @@ -256,7 +266,6 @@ static void vgic_reg_access(struct kvm_exit_mmio
> *mmio, u32 *reg,
> * directly (ARM ARM B3.12.7 "Prioritization of aborts").
> */
>
> - mask = (~0U) >> shift;
> if (reg) {
> regval = *reg;
> } else {
> @@ -265,7 +274,7 @@ static void vgic_reg_access(struct kvm_exit_mmio
> *mmio, u32 *reg,
> }
>
> if (mmio->is_write) {
> - u32 data = (*((u32 *)mmio->data) & mask) << shift;
> + u32 data = mmio_data_read(mmio, mask) << word_offset;
> switch (ACCESS_WRITE_MASK(mode)) {
> case ACCESS_WRITE_IGNORED:
> return;
> @@ -279,7 +288,7 @@ static void vgic_reg_access(struct kvm_exit_mmio
> *mmio, u32 *reg,
> break;
>
> case ACCESS_WRITE_VALUE:
> - regval = (regval & ~(mask << shift)) | data;
> + regval = (regval & ~(mask << word_offset)) | data;
> break;
> }
> *reg = regval;
> @@ -290,7 +299,7 @@ static void vgic_reg_access(struct kvm_exit_mmio
> *mmio, u32 *reg,
> /* fall through */
>
> case ACCESS_READ_VALUE:
> - *((u32 *)mmio->data) = (regval >> shift) & mask;
> + mmio_data_write(mmio, mask, regval >> word_offset);
> }
> }
> }
> @@ -702,6 +711,12 @@ bool vgic_handle_mmio(struct kvm_vcpu *vcpu,
> struct kvm_run *run,
> (mmio->phys_addr + mmio->len) > (base + KVM_VGIC_V2_DIST_SIZE))
> return false;
>
> + /* We don't support ldrd / strd or ldm / stm to the emulated vgic */
> + if (mmio->len > 4) {
> + kvm_inject_dabt(vcpu, mmio->phys_addr);
> + return true;
> + }
> +
> range = find_matching_range(vgic_ranges, mmio, base);
> if (unlikely(!range || !range->handle_mmio)) {
> pr_warn("Unhandled access %d %08llx %d\n",
> --
>
> Thanks,
> -Christoffer
>
--
Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <marc.zyngier@arm.com>
To: Christoffer Dall <c.dall@virtualopensystems.com>
Cc: Will Deacon <Will.Deacon@arm.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>
Subject: Re: [PATCH v5 04/12] ARM: KVM: Initial VGIC infrastructure code
Date: Tue, 15 Jan 2013 10:33:30 +0000 [thread overview]
Message-ID: <50F5307A.6000406@arm.com> (raw)
In-Reply-To: <CANM98q+y4GoHmqh-CS+fDnfbDbBQHQOY05urer5DMgy9b1X5ng@mail.gmail.com>
On 14/01/13 21:08, Christoffer Dall wrote:
> On Mon, Jan 14, 2013 at 10:31 AM, Will Deacon <will.deacon@arm.com> wrote:
>> As I mentioned previously, I suspect that this doesn't work with big-endian
>> systems. Whilst that's reasonable for the moment, a comment would be useful
>> for the unlucky soul that decides to do that work in future (or add
>> accessors for mmio->data as I suggested before).
>>
> admittedly this really hurts my brain, but I think there's actually no
> problem with endianness: whatever comes in mmio->data will have native
> endianness and the vgic is always little-endian, so a guest would have
> to make sure to do its own endianness conversion before writing data,
> or did I get this backwards? (some nasty feeling about if the OS is
> compiled in another endianness than the hardware everything may
> break).
>
> Anyhow, I think there's another bug in this code though. Please take a
> look and see if you agree:
>
> commit 3cab2b93a6f6acd3c043e584f23b94ab8f1bbd66
> Author: Christoffer Dall <c.dall@virtualopensystems.com>
> Date: Mon Jan 14 15:55:18 2013 -0500
>
> KVM: ARM: Limit vgic read/writes to load/store length
>
> The vgic read/write operations did not consider ldrb/strb masks, and
> would therefore unintentionally overwrite parts of a register.
>
> Consider for example a store of a single byte to a word-aligned address
> of one of the priority registers, that would cause the 3 most
> significant bytes to be overwritten with zeros.
>
> Cc: Marc Zyniger <marc.zyngier@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>
> diff --git a/arch/arm/kvm/vgic.c b/arch/arm/kvm/vgic.c
> index 25daa07..5c1bcf5 100644
> --- a/arch/arm/kvm/vgic.c
> +++ b/arch/arm/kvm/vgic.c
> @@ -233,6 +233,16 @@ static void vgic_cpu_irq_clear(struct kvm_vcpu
> *vcpu, int irq)
> vcpu->arch.vgic_cpu.pending_shared);
> }
>
> +static u32 mmio_data_read(struct kvm_exit_mmio *mmio, u32 mask)
> +{
> + return *((u32 *)mmio->data) & mask;
> +}
> +
> +static void mmio_data_write(struct kvm_exit_mmio *mmio, u32 mask, u32 value)
> +{
> + *((u32 *)mmio->data) = value & mask;
> +}
> +
> /**
> * vgic_reg_access - access vgic register
> * @mmio: pointer to the data describing the mmio access
> @@ -247,8 +257,8 @@ static void vgic_cpu_irq_clear(struct kvm_vcpu
> *vcpu, int irq)
> static void vgic_reg_access(struct kvm_exit_mmio *mmio, u32 *reg,
> phys_addr_t offset, int mode)
> {
> - int shift = (offset & 3) * 8;
> - u32 mask;
> + int word_offset = (offset & 3) * 8;
> + u32 mask = (1UL << (mmio->len * 8)) - 1;
> u32 regval;
>
> /*
> @@ -256,7 +266,6 @@ static void vgic_reg_access(struct kvm_exit_mmio
> *mmio, u32 *reg,
> * directly (ARM ARM B3.12.7 "Prioritization of aborts").
> */
>
> - mask = (~0U) >> shift;
> if (reg) {
> regval = *reg;
> } else {
> @@ -265,7 +274,7 @@ static void vgic_reg_access(struct kvm_exit_mmio
> *mmio, u32 *reg,
> }
>
> if (mmio->is_write) {
> - u32 data = (*((u32 *)mmio->data) & mask) << shift;
> + u32 data = mmio_data_read(mmio, mask) << word_offset;
> switch (ACCESS_WRITE_MASK(mode)) {
> case ACCESS_WRITE_IGNORED:
> return;
> @@ -279,7 +288,7 @@ static void vgic_reg_access(struct kvm_exit_mmio
> *mmio, u32 *reg,
> break;
>
> case ACCESS_WRITE_VALUE:
> - regval = (regval & ~(mask << shift)) | data;
> + regval = (regval & ~(mask << word_offset)) | data;
> break;
> }
> *reg = regval;
> @@ -290,7 +299,7 @@ static void vgic_reg_access(struct kvm_exit_mmio
> *mmio, u32 *reg,
> /* fall through */
>
> case ACCESS_READ_VALUE:
> - *((u32 *)mmio->data) = (regval >> shift) & mask;
> + mmio_data_write(mmio, mask, regval >> word_offset);
> }
> }
> }
> @@ -702,6 +711,12 @@ bool vgic_handle_mmio(struct kvm_vcpu *vcpu,
> struct kvm_run *run,
> (mmio->phys_addr + mmio->len) > (base + KVM_VGIC_V2_DIST_SIZE))
> return false;
>
> + /* We don't support ldrd / strd or ldm / stm to the emulated vgic */
> + if (mmio->len > 4) {
> + kvm_inject_dabt(vcpu, mmio->phys_addr);
> + return true;
> + }
> +
> range = find_matching_range(vgic_ranges, mmio, base);
> if (unlikely(!range || !range->handle_mmio)) {
> pr_warn("Unhandled access %d %08llx %d\n",
> --
>
> Thanks,
> -Christoffer
>
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2013-01-15 10:33 UTC|newest]
Thread overview: 158+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-08 18:41 [PATCH v5 00/12] KVM/ARM vGIC support Christoffer Dall
2013-01-08 18:41 ` Christoffer Dall
2013-01-08 18:41 ` [PATCH v5 01/12] KVM: ARM: Introduce KVM_SET_DEVICE_ADDRESS ioctl Christoffer Dall
2013-01-08 18:41 ` Christoffer Dall
2013-01-08 22:36 ` Scott Wood
2013-01-08 22:36 ` Scott Wood
2013-01-08 23:17 ` Christoffer Dall
2013-01-08 23:17 ` Christoffer Dall
2013-01-08 23:29 ` Scott Wood
2013-01-08 23:29 ` Scott Wood
2013-01-08 23:49 ` Christoffer Dall
2013-01-08 23:49 ` Christoffer Dall
2013-01-09 0:12 ` Scott Wood
2013-01-09 0:12 ` Scott Wood
2013-01-09 10:02 ` Alexander Graf
2013-01-09 10:02 ` Alexander Graf
2013-01-09 14:48 ` Peter Maydell
2013-01-09 14:48 ` Peter Maydell
2013-01-09 14:58 ` Alexander Graf
2013-01-09 14:58 ` Alexander Graf
2013-01-09 15:11 ` Peter Maydell
2013-01-09 15:11 ` Peter Maydell
2013-01-09 15:17 ` Christoffer Dall
2013-01-09 15:17 ` Christoffer Dall
2013-01-09 15:20 ` Alexander Graf
2013-01-09 15:20 ` Alexander Graf
2013-01-09 15:22 ` Marc Zyngier
2013-01-09 15:22 ` Marc Zyngier
2013-01-09 15:28 ` Alexander Graf
2013-01-09 15:28 ` Alexander Graf
2013-01-09 15:50 ` Marc Zyngier
2013-01-09 15:50 ` Marc Zyngier
2013-01-09 15:56 ` Alexander Graf
2013-01-09 15:56 ` Alexander Graf
2013-01-09 16:12 ` Marc Zyngier
2013-01-09 16:12 ` Marc Zyngier
2013-01-09 16:29 ` Christoffer Dall
2013-01-09 16:29 ` Christoffer Dall
2013-01-08 18:41 ` [PATCH v5 02/12] ARM: KVM: Keep track of currently running vcpus Christoffer Dall
2013-01-08 18:41 ` Christoffer Dall
2013-01-08 18:41 ` [PATCH v5 03/12] ARM: gic: define GICH offsets for VGIC support Christoffer Dall
2013-01-08 18:41 ` Christoffer Dall
2013-01-08 18:41 ` [PATCH v5 04/12] ARM: KVM: Initial VGIC infrastructure code Christoffer Dall
2013-01-08 18:41 ` Christoffer Dall
2013-01-14 15:31 ` Will Deacon
2013-01-14 15:31 ` Will Deacon
2013-01-14 21:08 ` Christoffer Dall
2013-01-14 21:08 ` Christoffer Dall
2013-01-14 21:28 ` [kvmarm] " Alexander Graf
2013-01-14 21:28 ` Alexander Graf
2013-01-14 22:50 ` Will Deacon
2013-01-14 22:50 ` Will Deacon
2013-01-15 10:33 ` Marc Zyngier [this message]
2013-01-15 10:33 ` Marc Zyngier
2013-01-08 18:41 ` [PATCH v5 05/12] ARM: KVM: VGIC accept vcpu and dist base addresses from user space Christoffer Dall
2013-01-08 18:41 ` Christoffer Dall
2013-01-08 18:42 ` [PATCH v5 06/12] ARM: KVM: VGIC distributor handling Christoffer Dall
2013-01-08 18:42 ` Christoffer Dall
2013-01-14 15:39 ` Will Deacon
2013-01-14 15:39 ` Will Deacon
2013-01-14 21:55 ` Christoffer Dall
2013-01-14 21:55 ` Christoffer Dall
2013-01-08 18:42 ` [PATCH v5 07/12] ARM: KVM: VGIC virtual CPU interface management Christoffer Dall
2013-01-08 18:42 ` Christoffer Dall
2013-01-14 15:42 ` Will Deacon
2013-01-14 15:42 ` Will Deacon
2013-01-14 22:02 ` Christoffer Dall
2013-01-14 22:02 ` Christoffer Dall
2013-01-15 11:00 ` Marc Zyngier
2013-01-15 11:00 ` Marc Zyngier
2013-01-15 14:31 ` Christoffer Dall
2013-01-15 14:31 ` Christoffer Dall
2013-01-16 15:29 ` Christoffer Dall
2013-01-16 15:29 ` Christoffer Dall
2013-01-16 16:09 ` Marc Zyngier
2013-01-16 16:09 ` Marc Zyngier
2013-01-16 16:13 ` Christoffer Dall
2013-01-16 16:13 ` Christoffer Dall
2013-01-16 16:17 ` [kvmarm] " Marc Zyngier
2013-01-16 16:17 ` Marc Zyngier
2013-01-08 18:42 ` [PATCH v5 08/12] ARM: KVM: vgic: retire queued, disabled interrupts Christoffer Dall
2013-01-08 18:42 ` Christoffer Dall
2013-01-08 18:42 ` [PATCH v5 09/12] ARM: KVM: VGIC interrupt injection Christoffer Dall
2013-01-08 18:42 ` Christoffer Dall
2013-01-08 18:42 ` [PATCH v5 10/12] ARM: KVM: VGIC control interface world switch Christoffer Dall
2013-01-08 18:42 ` Christoffer Dall
2013-01-08 18:42 ` [PATCH v5 11/12] ARM: KVM: VGIC initialisation code Christoffer Dall
2013-01-08 18:42 ` Christoffer Dall
2013-01-08 18:42 ` [PATCH v5 12/12] ARM: KVM: Add VGIC configuration option Christoffer Dall
2013-01-08 18:42 ` Christoffer Dall
2013-01-09 13:28 ` Sergei Shtylyov
2013-01-09 13:28 ` Sergei Shtylyov
2013-01-09 16:42 ` Christoffer Dall
2013-01-09 16:42 ` Christoffer Dall
2013-01-09 16:26 ` [PATCH v5.1 0/2] KVM: ARM: Rename KVM_SET_DEVICE_ADDRESS Christoffer Dall
2013-01-09 16:26 ` Christoffer Dall
2013-01-09 16:26 ` [PATCH v5.1 1/2] KVM: ARM: Introduce KVM_SET_DEVICE_ADDRESS ioctl Christoffer Dall
2013-01-09 16:26 ` Christoffer Dall
2013-01-09 16:26 ` [PATCH v5.1 2/2] ARM: KVM: VGIC accept vcpu and dist base addresses from user space Christoffer Dall
2013-01-09 16:26 ` Christoffer Dall
2013-01-09 16:48 ` [kvmarm] [PATCH v5.1 0/2] KVM: ARM: Rename KVM_SET_DEVICE_ADDRESS Alexander Graf
2013-01-09 16:48 ` Alexander Graf
2013-01-09 19:50 ` Scott Wood
2013-01-09 19:50 ` Scott Wood
2013-01-09 20:12 ` Alexander Graf
2013-01-09 20:12 ` Alexander Graf
2013-01-09 21:15 ` Scott Wood
2013-01-09 21:15 ` Scott Wood
2013-01-09 21:37 ` Alexander Graf
2013-01-09 21:37 ` Alexander Graf
2013-01-09 22:10 ` Scott Wood
2013-01-09 22:10 ` Scott Wood
2013-01-09 22:26 ` Christoffer Dall
2013-01-09 22:26 ` Christoffer Dall
2013-01-09 22:34 ` Alexander Graf
2013-01-09 22:34 ` Alexander Graf
2013-01-10 11:15 ` Alexander Graf
2013-01-10 11:15 ` Alexander Graf
2013-01-10 11:18 ` Gleb Natapov
2013-01-10 11:18 ` Gleb Natapov
2013-01-09 22:30 ` Alexander Graf
2013-01-09 22:30 ` Alexander Graf
2013-01-10 10:17 ` Peter Maydell
2013-01-10 10:17 ` Peter Maydell
2013-01-10 11:06 ` Alexander Graf
2013-01-10 11:06 ` Alexander Graf
2013-01-10 11:53 ` Marc Zyngier
2013-01-10 11:53 ` Marc Zyngier
2013-01-10 11:57 ` Alexander Graf
2013-01-10 11:57 ` Alexander Graf
2013-01-10 22:28 ` Marcelo Tosatti
2013-01-10 22:28 ` Marcelo Tosatti
2013-01-10 22:40 ` Scott Wood
2013-01-10 22:40 ` Scott Wood
2013-01-11 0:35 ` Marcelo Tosatti
2013-01-11 0:35 ` Marcelo Tosatti
2013-01-11 1:10 ` Scott Wood
2013-01-11 1:10 ` Scott Wood
2013-01-11 7:26 ` Christoffer Dall
2013-01-11 7:26 ` Christoffer Dall
2013-01-11 18:39 ` Marcelo Tosatti
2013-01-11 18:39 ` Marcelo Tosatti
2013-01-11 19:11 ` Alexander Graf
2013-01-11 19:11 ` Alexander Graf
2013-01-11 19:18 ` Marcelo Tosatti
2013-01-11 19:18 ` Marcelo Tosatti
2013-01-11 19:33 ` Christoffer Dall
2013-01-11 19:33 ` Christoffer Dall
2013-01-11 15:42 ` Alexander Graf
2013-01-11 15:42 ` Alexander Graf
2013-01-11 20:11 ` Scott Wood
2013-01-11 20:11 ` Scott Wood
2013-01-11 20:26 ` Alexander Graf
2013-01-11 20:26 ` Alexander Graf
2013-01-11 19:17 ` Alexander Graf
2013-01-11 19:17 ` Alexander Graf
2013-01-10 22:21 ` Marcelo Tosatti
2013-01-10 22:21 ` Marcelo Tosatti
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=50F5307A.6000406@arm.com \
--to=marc.zyngier@arm.com \
--cc=linux-arm-kernel@lists.infradead.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.