linux-kernel - Re: [PATCH v4 6/8] firmware: qcom: scm: add modparam to control QSEECOM enablement

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: <aG-KcWsztfTUHE0Y@hovoldconsulting.com>
Date: Thu, 10 Jul 2025 11:40:01 +0200
From: Johan Hovold <johan@...nel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Bjorn Andersson <andersson@...nel.org>,
	Maximilian Luz <luzmaximilian@...il.com>,
	Konrad Dybcio <konradybcio@...nel.org>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Ard Biesheuvel <ardb@...nel.org>,
	Steev Klimaszewski <steev@...i.org>, linux-arm-msm@...r.kernel.org,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	linux-efi@...r.kernel.org,
	Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
	Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Subject: Re: [PATCH v4 6/8] firmware: qcom: scm: add modparam to control
 QSEECOM enablement

On Tue, Jul 01, 2025 at 02:10:49PM +0300, Dmitry Baryshkov wrote:
> On Mon, Jun 30, 2025 at 02:42:06PM +0200, Johan Hovold wrote:

> > Here it's just Qualcomm doing something funny that affects their own
> > platforms. We should be able to figure this out without forcing users or
> > distros to pass command line parameters.
> 
> This is not intended for the normal working course, but for the initial
> bringup / nailing out issues after the bringup (e.g. after firmware
> upgrade).

And for that you do not need a module parameter either.

> > Do we know if there are any sc8280xp or x1e machines that boot off UFS?
> > 
> > If not (even with the exception of the CRDs) then it should be fine to
> > just whitelist the SoCs without any command line parameters.
> 
> I'm not aware of such platforms.

Then go for it.

> > Adding to a blacklist is bound to be overlooked, while adding to a
> > whitelist is not.
> 
> You can't overlook it since it is required as a part of almost any
> distro setup - point UEFI boot sequence to your new bootloader entry.

The distros don't do bring ups of these machines themselves.

> > I'd rather see you get to the bottom of the UFS boot issue and whether
> > there is some way to determine this programmatically.
> 
> I don't see a good way to do that - UFS might be probed very late, it
> might be unused for the boot at all, etc.

How about asking the Qualcomm firmware team?

Again, there's no rush here. Whitelisting is perfectly fine until then.

> > If everything that's currently upstream boots from NVMe that may not
> > necessarily mean it works for devices using UFS.
> 
> And? I don't care that much about theoretical devices here.

It's not theoretical. We know that the UEFI vars on the CRDs are not
persistent when booting off UFS. Not to mention your Yoga.

> > > > But if this series now enables broken EFI variable support on every
> > > > other device then I don't think that's ok (even if you provide a command
> > > > line parameter that each user now have to pass).
> > > > 
> > > > Then I'd rather see a proposal for how to determine which machines
> > > > support this or not, information which was not available when this
> > > > interface was reverse engineered and where a conservative whitelist
> > > > approach made perfect sense.
> > > 
> > > WIP
> > 
> > Good. We can manage with adding new entries for a while still while you
> > guys at Qualcomm work this out.
> 
> You (we) guys at Linaro could have figured that out too ;-)

Linaro relies on Qualcomm to provide details on things like this. As you
know.

Johan