linux-kernel - Re: [PATCH V18 6/9] KVM: arm64: nvhe: Disable branch generation in nVHE guests

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] [day] [month] [year] [list]

Date: Fri, 21 Jun 2024 14:12:49 +0100
From: Mark Rutland <mark.rutland@....com>
To: Anshuman Khandual <anshuman.khandual@....com>
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	will@...nel.org, catalin.marinas@....com,
	Mark Brown <broonie@...nel.org>, James Clark <james.clark@....com>,
	Rob Herring <robh@...nel.org>, Marc Zyngier <maz@...nel.org>,
	Suzuki Poulose <suzuki.poulose@....com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	linux-perf-users@...r.kernel.org,
	Oliver Upton <oliver.upton@...ux.dev>,
	James Morse <james.morse@....com>, kvmarm@...ts.linux.dev
Subject: Re: [PATCH V18 6/9] KVM: arm64: nvhe: Disable branch generation in
 nVHE guests

On Thu, Jun 20, 2024 at 09:52:05AM +0530, Anshuman Khandual wrote:
> On 6/17/24 15:09, Mark Rutland wrote:
> > On Mon, Jun 17, 2024 at 12:15:15PM +0530, Anshuman Khandual wrote:
> >> On 6/14/24 20:53, Mark Rutland wrote:
> >>> On Thu, Jun 13, 2024 at 11:47:28AM +0530, Anshuman Khandual wrote:
> >>>> Disable the BRBE before we enter the guest, saving the status and enable it
> >>>> back once we get out of the guest. This avoids capturing branch records in
> >>>> the guest kernel or userspace, which would be confusing the host samples.
> >>>
> >>> It'd be good to explain why we need to do this for nVHE, but not for
> >>> VHE. I *think* that you're relying on BRBCR_EL2.EL0HBRE being ignored
> >>> when HCR_EL2.TGE == 0, and BRBCR_EL1.E{1,0}BRE being initialized to 0
> >>> out-of-reset.
> >>
> >> That's right, there is no possibility for the host and guest BRBE config
> >> to overlap.
> >>
> >>> What should a user do if they *want* samples from a guest? Is that
> >>
> >> That is not supported currently. But in order to enable capturing guest
> >> branch samples from inside the host - BRBCR_EL2 configs need to migrate
> >> into BRBCR_EL1 when the guest runs on the cpu.
> >>
> >>> possible to do on other architectures, or do is that always prevented?
> >>
> >> I am not sure about other architectures, but for now this falls within
> >> guest support which might be looked into later. But is not the proposed
> >> patch complete in itself without any further guest support ?
> > 
> > My concern here is ABI rather than actual support.
> I am trying to understand how this is an ABI problem. Because perf debug
> tools could be described as - a best effort based sample collection. All
> samples that could be collected for a given perf_event_attr request might
> change if the underlying assumptions change later on. AFAICT semantics of
> expectations for a given attribute request is not a hard ABI requirement.

The ABI requirements are certainly unclear, but people get *very* upset
when behaviour changes, so I think we need to have some certainty that
we're not backing ourselves into a corner where we have to make
substantial behavioural changes later.

Surely we can figure out how this works on other architectures today?

There's a substantial argument for aligning with x86, so can we figure
out under which conditions x86 would provide guest samples? e.g. is that
always, never, or when certain attr options are configured?

> > It's not clear to me how this works across architectures, and we should
> > have some idea of how this would work (e.g. if we're going to require
> > new ABI or not), so that we don't have to break ABI later on.
> 
> BRBE HW does not have any guest filter in itself, unless BRBCR_EL2 gets
> migrated across BRBCR_EL1 during guest transition, guest branch records
> would not be captured.
> 
> event->attr.exclude_guest = 0 could have been denied during armpmu_add()
> for preventing events with guest branch sample requests being scheduled
> on the PMU. But it turns out to be not a very reliable parameter in that
> sense as well.
> 
> event->attr.exclude_guest = 0 remains clear even for a standard session.
> 
> ./perf record -e instructions:k -j any_call,save_type ls
> 
> perf tools will need some changes in order to avoid the above scenarios
> as a default behaviour which would not be desirable as well.

If we're liable to need perf tool changes, then we *definitely* need to
understand this better.

> These semantics could be worked out later on when BRBE guest support gets
> included, and the current proposal would not prevent any potential future
> changes in this regard.

That depends entirely on what changes we'd expect would be necessary in
the perf tools. We need to be certain that we don't enable some use case
that subseuqent changes break.

Mark.