linux-kernel - Re: [PATCH 1/2] KVM: arm64: vgic: Forbid invalid userspace Redistributor accesses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 15 Nov 2020 17:04:01 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Zenghui Yu <yuzenghui@...wei.com>
Cc:     kvmarm@...ts.cs.columbia.edu, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, eric.auger@...hat.com,
        james.morse@....com, julien.thierry.kdev@...il.com,
        suzuki.poulose@....com, wanghaibin.wang@...wei.com,
        Keqian Zhu <zhukeqian1@...wei.com>
Subject: Re: [PATCH 1/2] KVM: arm64: vgic: Forbid invalid userspace
 Redistributor accesses

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. 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.

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...).

Thoughts?

         M.
-- 
Jazz is not dead. It just smells funny...