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

On 2020-11-17 09:59, Auger Eric wrote:
> Hi Marc,
> 
> On 11/17/20 9:49 AM, Marc Zyngier wrote:
>> Hi Zenghui,
>> 
>> On 2020-11-16 14:57, Zenghui Yu wrote:
>>> Hi Marc,
>>> 
>>> On 2020/11/16 22:10, Marc Zyngier wrote:
>>>>> 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".
>>>> 
>>>> I'd tend to agree, but it is just that this is a large change at 
>>>> -rc4.
>>>> I'd rather have a quick fix for 5.10, and a more invasive change for
>>>> 5.11,
>>>> spanning all the possible vgic devices.
>>> 
>>> So you prefer fixing it by "return a value that doesn't have the Last
>>> bit set" for v5.10? I'm ok with it and can send v2 for it.
>> 
>> Cool. Thanks for that.
>> 
>>> Btw, looking again at the way we handle the user-reading of 
>>> GICR_TYPER
>>> 
>>>     vgic_mmio_read_v3r_typer(vcpu, addr, len)
>>> 
>>> it seems that @addr is actually the *offset* of GICR_TYPER (0x0008) 
>>> and
>>> @addr is unlikely to be equal to last_rdist_typer, which is the *GPA* 
>>> of
>>> the last RD. Looks like the user-reading of GICR_TYPER.Last is always
>>> broken?
>> 
>> I think you are right. Somehow, we don't seem to track the index of
>> the RD in the region, so we can never compute the address of the RD
>> even if the base address is set.
>> 
>> Let's drop the reporting of Last for userspace for now, as it never
>> worked. If you post a patch addressing that quickly, I'll get it to
>> Paolo by the end of the week (there's another fix that needs merging).
>> 
>> Eric: do we have any test covering the userspace API?
> 
> So as this issue seems related to the changes made when implementing 
> the
> multiple RDIST regions, I volunteer to write those KVM selftests :-)

You're on! :D

More seriously, there is scope for fuzzing the device save/restore API,
as we find bugs every time someone change the "known good" ordering that
is implemented in QEMU.

Maybe it means getting rid of some unnecessary flexibility, as proposed
by Zenghui, if we are confident that no userspace makes use of it.
And in the future, making sure that new APIs are rigid enough to avoid 
such
bugs.

Thanks,

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