kvmarm.lists.cs.columbia.edu archive mirror
 help / color / mirror / Atom feed
From: Zenghui Yu <yuzenghui@huawei.com>
To: Marc Zyngier <maz@kernel.org>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH 1/2] KVM: arm64: vgic: Forbid invalid userspace Redistributor accesses
Date: Mon, 16 Nov 2020 21:09:52 +0800	[thread overview]
Message-ID: <584b7ff1-ecf2-b0ec-cea3-ccc29902f43a@huawei.com> (raw)
In-Reply-To: <724c43702b52aac0d3c9beb9604d1bfb@kernel.org>

Hi Marc,

On 2020/11/16 1:04, Marc Zyngier wrote:
> Hi Zenghui,
> 
> On 2020-11-13 14:28, Zenghui Yu wrote:
>> It's expected that users will access registers in the redistributor *if*
>> the RD has been initialized properly. Unfortunately userspace can be 
>> bogus
>> enough to access registers before setting the RD base address, and KVM
>> implicitly allows it (we handle the access anyway, regardless of whether
>> the base address is set).
>>
>> Bad thing happens when we're handling the user read of GICR_TYPER. We end
>> up with an oops when deferencing the unset rdreg...
>>
>>     gpa_t last_rdist_typer = rdreg->base + GICR_TYPER +
>>             (rdreg->free_index - 1) * KVM_VGIC_V3_REDIST_SIZE;
>>
>> Fix this issue by informing userspace what had gone wrong (-ENXIO).
> 
> I'm worried about the "implicit" aspect of the access that this patch
> now forbids.
> 
> The problem is that the existing documentation doesn't cover this case, > and -ENXIO's "Getting or setting this register is not yet supported"
> is way too vague.

Indeed. How about changing to

     -ENXIO  Getting or setting this register is not yet supported
             or VGIC not properly configured (e.g., [Re]Distributor base
             address is unknown)

> There is a precedent with the ITS, but that's 
> undocumented
> as well. Also, how about v2? If that's the wasy we are going to fix this,
> we also nned to beef up the documentation.

Sure, I plan to do so and hope it won't break the existing userspace.

> Of course, the other horrible way to address the issue is to return a value
> that doesn't have the Last bit set, since we can't synthetise it. It 
> doesn't
> change the userspace API, and I can even find some (admittedly  twisted)
> logic to it (since there is no base address, there is no last RD...).

I'm fine with it. But I'm afraid that there might be other issues due to
the "unexpected" accesses since I haven't tested with all registers from
userspace.

My take is that only if the "[Re]Distributor base address" is specified
in the system memory map, will the user-provided kvm_device_attr.offset
make sense. And we can then handle the access to the register which is
defined by "base address + offset".


Thanks,
Zenghui
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

  reply	other threads:[~2020-11-16 13:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-13 14:27 [PATCH 0/2] KVM: arm64: vgic: Fix handling of userspace register accesses Zenghui Yu
2020-11-13 14:28 ` [PATCH 1/2] KVM: arm64: vgic: Forbid invalid userspace Redistributor accesses Zenghui Yu
2020-11-15 17:04   ` Marc Zyngier
2020-11-16 13:09     ` Zenghui Yu [this message]
2020-11-16 14:10       ` Marc Zyngier
2020-11-16 14:57         ` Zenghui Yu
2020-11-17  8:49           ` Marc Zyngier
2020-11-17  9:47             ` Auger Eric
2020-11-17  9:59             ` Auger Eric
2020-11-17 10:51               ` Marc Zyngier
2020-11-17 13:09             ` Zenghui Yu
2020-11-13 14:28 ` [PATCH 2/2] KVM: arm64: vgic: Forbid invalid userspace Distributor accesses Zenghui Yu

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=584b7ff1-ecf2-b0ec-cea3-ccc29902f43a@huawei.com \
    --to=yuzenghui@huawei.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).