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  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, 8 Jan 2021 14:15:22 +0000
From:   Suzuki K Poulose <>
To:     Mathieu Poirier <>
Subject: Re: [PATCH v6 00/26] coresight: etm4x: Support for system

Hi Mathieu,

Please hold on with this series, I will update the series, fixing the
issues you have spotted and some additional patches to prevent accesses
to all the system registers that may not be available via system instructions.

Apologies for the inconvenience

Kind regards

On 1/8/21 9:08 AM, Suzuki K Poulose wrote:
> Hi Mathieu
> On 1/8/21 1:09 AM, Mathieu Poirier wrote:
>> Hi Suzuki,
>> On Thu, Jan 07, 2021 at 12:38:33PM +0000, Suzuki K Poulose wrote:
>>> CoreSight ETMv4.4 obsoletes memory mapped access to ETM and
>>> mandates the system instructions for registers.
>>> This also implies that they may not be on the amba bus.
>>> Right now all the CoreSight components are accessed via memory
>>> map. Also, we have some common routines in coresight generic
>>> code driver (e.g, CS_LOCK, claim/disclaim), which assume the
>>> mmio. In order to preserve the generic algorithms at a single
>>> place and to allow dynamic switch for ETMs, this series introduces
>>> an abstraction layer for accessing a coresight device. It is
>>> designed such that the mmio access are fast tracked (i.e, without
>>> an indirect function call).
>>> This will also help us to get rid of the driver+attribute specific
>>> sysfs show/store routines and replace them with a single routine
>>> to access a given register offset (which can be embedded in the
>>> dev_ext_attribute). This is not currently implemented in the series,
>>> but can be achieved.
>>> Further we switch the generic routines to work with the abstraction.
>>> With this in place, we refactor the etm4x code a bit to allow for
>>> supporting the system instructions with very little new code.
>>> We use TRCDEVARCH for the detection of the ETM component, which
>>> is a standard register as per CoreSight architecture, rather than
>>> the etm specific id register TRCIDR1. This is for making sure
>>> that we are able to detect the ETM via system instructions accurately,
>>> when the the trace unit could be anything (etm or a custom trace unit).
>>> To keep the backward compatibility for any existing broken
>>> impelementation which may not implement TRCDEVARCH, we fall back to TRCIDR1.
>>> Also this covers us for the changes in the future architecture [0].
>>> Also, v8.4 self-hosted tracing extensions (coupled with ETMv4.4) adds
>>> new filtering registers for trace by exception level. So on a v8.4
>>> system, with Trace Filtering support, without the appropriate
>>> programming of the Trace filter registers (TRFCR_ELx), tracing
>>> will not be enabled. This series also includes the TraceFiltering
>>> support to cover the ETM-v4.4 support.
>>> The series has been mildly tested on a model for system instructions.
>>> I would really appreciate any testing on real hardware.
>> I have queued your work in my local tree.  I will have a final pass before
>> pushing to coresight-next tomorrow or on Monday.
> Thanks for the review and fixups. Please let me know if you need a respin.
> Cheers
> Suzuki

Powered by blists - more mailing lists