linux-kernel - Re: [PATCH v4 2/7] arm64: KVM: Use shared area to pass PMU event state to hypervisor

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: Mon, 5 Feb 2024 15:37:34 +0000
From: James Clark <james.clark@....com>
To: Marc Zyngier <maz@...nel.org>
Cc: Oliver Upton <oliver.upton@...ux.dev>, coresight@...ts.linaro.org,
 linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
 broonie@...nel.org, suzuki.poulose@....com, acme@...nel.org,
 James Morse <james.morse@....com>, Zenghui Yu <yuzenghui@...wei.com>,
 Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
 Mike Leach <mike.leach@...aro.org>, Leo Yan <leo.yan@...aro.org>,
 Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
 Anshuman Khandual <anshuman.khandual@....com>, Rob Herring
 <robh@...nel.org>, Miguel Luis <miguel.luis@...cle.com>,
 Jintack Lim <jintack.lim@...aro.org>, Ard Biesheuvel <ardb@...nel.org>,
 Mark Rutland <mark.rutland@....com>, Arnd Bergmann <arnd@...db.de>,
 Vincent Donnefort <vdonnefort@...gle.com>,
 Kristina Martsenko <kristina.martsenko@....com>,
 Fuad Tabba <tabba@...gle.com>, Joey Gouly <joey.gouly@....com>,
 Akihiko Odaki <akihiko.odaki@...nix.com>, Jing Zhang
 <jingzhangos@...gle.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 2/7] arm64: KVM: Use shared area to pass PMU event
 state to hypervisor



On 05/02/2024 14:52, Marc Zyngier wrote:
> On Mon, 05 Feb 2024 14:17:10 +0000,
> James Clark <james.clark@....com> wrote:
>>
>> On 05/02/2024 13:21, Oliver Upton wrote:
>>> On Mon, Feb 05, 2024 at 01:15:36PM +0000, Marc Zyngier wrote:
>>>> On Mon, 05 Feb 2024 13:04:51 +0000,
>>>> Oliver Upton <oliver.upton@...ux.dev> wrote:
>>>>>
>>>>> Unless someone has strong opinions about making this work in protected
>>>>> mode, I am happy to see tracing support limited to the 'normal' nVHE
>>>>> configuration. The protected feature as a whole is just baggage until
>>>>> upstream support is completed.
>>>>
>>>> Limiting tracing to non-protected mode is a must IMO. Allowing tracing
>>>> when pKVM is enabled is a sure way to expose secrets that should
>>>> stay... secret. The only exception I can think of is when
>>>> CONFIG_NVHE_EL2_DEBUG is enabled, at which point all bets are off.
>>>
>>> Zero argument there :) I left off the "and PMU" part of what I was
>>> saying, because that was a feature that semi-worked in protected mode
>>> before VM/VCPU shadowing support landed.
>>>
>>
>> In that case I can hide all this behind CONFIG_NVHE_EL2_DEBUG for pKVM.
>> This will also have the effect of disabling PMU again for pKVM because I
>> moved that into this new shared area.
> 
> I'm not sure what you have in mind, but dropping PMU support for
> non-protected guests when protected-mode is enabled is not an
> acceptable outcome.
> 
> Hiding the trace behind a debug option is fine as this is a global
> setting that has no userspace impact, but impacting guests isn't.
> 
> 	M.
> 

Hmmm in that case if there's currently no way to distinguish between
normal VMs and pVMs in protected-mode then what I was thinking of
probably won't work.

I'll actually just leave PMU as it is and only have tracing disabled in
protected-mode.

My only question now is whether to:

 * Keep this new shared area and use it for both PMU and trace status
   (well, for PMU only in protected mode as trace would always be
   disabled and doesn't actually need any state)

 * Delete patch 2, add a new normal per-cpu struct just for
   trace status that's only used in non-protected mode and revert to
   copying the PMU status into the vCPU on guest switch as it was
   previously.