linux-kernel - Re: [RFC PATCH 0/3] coresight: Support exclude_guest with Feat

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <86edki62vz.wl-maz@kernel.org>
Date:   Fri, 04 Aug 2023 20:09:20 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     James Clark <james.clark@....com>
Cc:     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>,
        Suzuki K Poulose <suzuki.poulose@....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 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).

Thanks,

	M.

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