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]
Message-ID: <8c7be69b-2227-45c2-9096-a49ec6df9a09@linaro.org>
Date: Fri, 28 Nov 2025 14:53:03 +0000
From: James Clark <james.clark@...aro.org>
To: Leo Yan <leo.yan@....com>, Mike Leach <mike.leach@...aro.org>
Cc: Kuan-Wei Chiu <visitorckw@...il.com>, suzuki.poulose@....com,
 alexander.shishkin@...ux.intel.com, pratikp@...eaurora.org,
 mathieu.poirier@...aro.org, gregkh@...uxfoundation.org,
 jserv@...s.ncku.edu.tw, marscheng@...gle.com, ericchancf@...gle.com,
 milesjiang@...gle.com, nickpan@...gle.com, coresight@...ts.linaro.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] coresight: etm3x: Fix buffer overwrite in cntr_val_show()



On 27/11/2025 9:29 am, Leo Yan wrote:
> On Wed, Nov 26, 2025 at 04:14:19PM +0000, Mike Leach wrote:
> 
> [...]
> 
>>>> The key to this is not the questions we are asked, but which platforms
>>>> are still supported by the linux kernel.
>>>>
>>>> The ETMv3 driver supports both ETMv3 and PTM trace (the programming
>>>> model is the same, even if the trace decode is vastly different).
>>>>
>>>> So as long as there are  platforms supported that use either of those,
>>>> we need to keep the driver in.
>>>>
>>>
>>> We're not running tests though, so if we find out it's fundamentally
>>> broken somehow it could be another justification to remove it, even if
>>> the kernel supports the devices. Do you have a board that you can test
>>> on Mike?
>>
>> Don't have one myself, but I believe the TC2 was used in development,
>> (that's the A15/A7 32 bit part - not total compute!) which somewhat
>> conveniently had both etmv3 and ptm trace.
> 
> If ETMv4 can be used by Armv7 (arm32) CPUs, and nowdays if Armv7 + ETMv4
> is a popular design, it makes sense for me to remove ETMv3 driver.
> 
> If Armv7 CPUs are always bound to ETMv3 / PTM, then we should keep the
> driver.
> 
> Thanks,
> Leo

Based on the the build system I don't think what the hardware supports 
matters that much. We've always only built the ETM4 driver on Arm64 and 
only build the ETM3 driver on Arm32.

I just found another bug which I think makes sense to log here. We've 
pretty much always turned on timestamps automatically in Perf, but for 
some reason the option validator in Perf thinks they're not supported in 
ETM3. The driver has always accepted it as an option so I'm not sure 
why. The end result is that the command will always fail, and you 
couldn't even undo it with "timestamp=0" until more recently when I 
fixed that.

Sysfs or per-thread Perf mode would be working, but it's one more bit of 
evidence to take in.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ