linux-kernel - Re: [PATCH v3 0/4] KVM: arm64: writable MIDR/REVIDR

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]

Message-ID: <b2b015de-569b-2cdd-8ec3-8c8690ff950b@redhat.com>
Date: Wed, 26 Feb 2025 17:47:53 +0100 (CET)
From: Sebastian Ott <sebott@...hat.com>
To: Oliver Upton <oliver.upton@...ux.dev>
cc: Marc Zyngier <maz@...nel.org>, Joey Gouly <joey.gouly@....com>, 
    Suzuki K Poulose <suzuki.poulose@....com>, 
    Zenghui Yu <yuzenghui@...wei.com>, 
    Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, 
    Shameer Kolothum <shameerali.kolothum.thodi@...wei.com>, 
    Cornelia Huck <cohuck@...hat.com>, Eric Auger <eric.auger@...hat.com>, 
    linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev, 
    linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/4] KVM: arm64: writable MIDR/REVIDR

Hi Oliver,

On Mon, 24 Feb 2025, Oliver Upton wrote:
> On Tue, Feb 18, 2025 at 05:34:39PM +0100, Sebastian Ott wrote:
>> Based on prior discussion [1] this series allows VMMs to change
>> MIDR/REVIDR to enable migration between machines that differ in
>> these registers. Since these are used for errata handling the
>> errata management series [2] is a prerequisite for this one.
>>
>> changes for V3:
>> * handle VPIDR_EL2 as part of vcpu ctxt - thanks Oliver!
>
> Thanks for respinning. While your changes are looking good, as I got
> ready to apply this series I wound up peeling the onion a bit further
> and have a few more concerns:
>
> - Current KVM allows guests to read SMIDR_EL1 despite the fact that we
>   do not support SME (this is part of TID1 traps)
>
> - The "invariant" values that KVM presents to userspace originate from
>   the boot CPU, not the CPU that resets the ID registers for a VM
>
> - A VMM that wants to present big-little can do so on current KVM by
>   affining vCPUs, but cannot with this series
>
> All of this is to say, I think your series is going to collide with
> the pre-existing pile of crap we have. I'm going to pick up these
> changes and rework them so we can send a fix for #1 to stable trees and
> (hopefully) avoid breaking the old "invariant" behavior.
>
> I'll post what I have as soon as I test it, hopefully we can get this
> shaped up for 6.15.

Sry, for the additional work I've caused. I gave what you have in next a
spin and it looks good so far.
Thank you very much!

Sebastian