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, 08 Aug 2023 12:06:45 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Suzuki K Poulose <suzuki.poulose@....com>
Cc:     James Clark <james.clark@....com>, coresight@...ts.linaro.org,
        linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
        Oliver Upton <oliver.upton@...ux.dev>,
        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>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] coresight: Support exclude_guest with Feat_TRF and nVHE

On Sat, 05 Aug 2023 11:28:39 +0100,
Suzuki K Poulose <suzuki.poulose@....com> wrote:
> 
> Hi Marc
> 
> On 04/08/2023 20:09, Marc Zyngier wrote:
> > On Fri, 04 Aug 2023 11:13:10 +0100,
> > James Clark <james.clark@....com> wrote:
> >> 
> >> Hi,
> >> 
> >> I'm looking for help in testing this and for feedback on whether it's
> >> useful to anyone. Testing it requires hardware that has Feat_TRF (v8.4)
> >> but no TRBE. This is because TRBE usage is disabled in nVHE guests.
> >> 
> >> I don't currently have any access to any hardware, and the FVP model
> >> can only do self hosted trace using TRBE.
> >> 
> >> Currently with nVHE you would always get trace from guests, and
> >> filtering out isn't possible without this patchset. In comparison, with
> >> VHE guests, they never generate guest trace without [1]. I think the
> >> existence of trace rather than lack of could suggest that this change is
> >> less useful than [1]. Also the restricted set of hardware that it works
> >> on supports that too.
> > 
> > It'd be nice to have some sort of feature parity, but it seems like a
> > vanishingly small target of users having access to an ETM sink.
> > 
> >> 
> >> Apart from compilation and checking that the exclude guest settings
> >> are correctly programmed on guest switch, this is untested by me.
> > 
> > I'll have a look at the series, but none of my HW fits in this
> > description (my ARMv8.4+ boxes don't have any form of tracing).
> 
> While I have your attention, we have another series that manages the
> trace filtering for Guests on VHE, completely within the Coresight etm4x
> driver here [0]. I personally think, it is good to have the guest
> filtering for both nVHE and VHE under the KVM control, like we do
> in this series. I would like your opinion on this.

I just quickly reviewed the first two patches of the nVHE series, and
I think the shape is a bit wrong. I can absolutely see the interest of
preventing extra tracing when a guest is running, but the way this is
currently plugged makes it hard to reason about it.

> [0] https://lkml.kernel.org/r/20230804085219.260790-1-james.clark@arm.com

I'll try to have a look at that one later.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ