linux-kernel - Re: [PATCH 0/4] Add tooling to disable debugfs on OMAP based systems

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: <253085958.4428.1764429515315.JavaMail.zimbra@nod.at>
Date: Sat, 29 Nov 2025 16:18:35 +0100 (CET)
From: Richard Weinberger <richard@....at>
To: Andreas Kemnade <andreas@...nade.info>
Cc: linux-kernel <linux-kernel@...r.kernel.org>, linux-omap@...r.kernel.org, 
	devicetree <devicetree@...r.kernel.org>, 
	Arnd Bergmann <arnd@...db.de>, Lee Jones <lee@...nel.org>, 
	dakr@...nel.org, "Rafael J. Wysocki" <rafael@...nel.org>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	Mark Brown <broonie@...nel.org>, tony@...mide.com, rogerq@...nel.org, 
	khilman@...libre.com, aaro koskinen <aaro.koskinen@....fi>, 
	Conor Dooley <conor+dt@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, robh <robh@...nel.org>
Subject: Re: [PATCH 0/4] Add tooling to disable debugfs on OMAP based
 systems

----- Ursprüngliche Mail -----
> Von: "Andreas Kemnade" <andreas@...nade.info>
> it is usually not about individual registers, but about accessing
> unpowered devices/modules,
> 
> so it is probably more the logic like:
> 
> if (pm_runtime_is_suspended(regmap->device))
>	-EACCESS;
> 
> Try to play around with on >power/control in sysfs.

Well the that regmap is owned by the syscon mfd.
And in case of CTRL_MODULE_CORE only accessing some reserved registers causes
an abort.

For registers like dsp_system@...00000 it's maybe indeed due to an unpowered module.
I'll double check that.
 
>> So, add tooling to allow disabling debugfs access to such dangerous registers.
>> Splitting the register map definitions in the device tree seemed less practical
>> to
>> me since it would unnecessarily make the device trees more complicated.
>> 
> So is it really a description of the hardware? Maybe there are some special
> cases, too.

IMHO, "There are problematic registers, don't blindly mess with them" is a description of the hardware.

Thanks,
//richard