linux-kernel - Re: [PATCH v2 2/4] firmware: qcom: uefisecapp: add support for R/O UEFI vars

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: <aF0WGmnN_8rvI9n1@hovoldconsulting.com>
Date: Thu, 26 Jun 2025 11:42:50 +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>, linux-arm-msm@...r.kernel.org,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 2/4] firmware: qcom: uefisecapp: add support for R/O
 UEFI vars

On Tue, Jun 24, 2025 at 04:13:34AM +0300, Dmitry Baryshkov wrote:
> On Mon, Jun 23, 2025 at 04:50:27PM +0200, Johan Hovold wrote:
> > On Mon, Jun 23, 2025 at 04:45:30PM +0200, Johan Hovold wrote:

> > > Also not sure how useful it is to only be able to read variables,
> > > including for the RTC where you'll end up with an RTC that's always
> > > slightly off due to drift (even if you can set it when booting into
> > > Windows or possibly from the UEFI setup).
> > > 
> > > Don't you have any SDAM blocks in the PMICs that you can use instead for
> > > a proper functioning RTC on these machines?
> 
> I'd rather not poke into an SDAM, especially since we don't have docs
> which SDAM blocks are used and which are not.

You're with Qualcomm now so you should be able to dig up this
information like we did for the X13s (even if I'm quite aware that it
may still be easier said than done).

> I think the slightly drifted RTC is still much better than ending up
> with an RTC value which is significantly off, because it was set via the
> file modification time.

I measured drift of 1 second every 3.5 h on the X13s, so having an
almost correct time with massive drift that cannot be corrected for may
not necessarily be better.

> Anyway, let me pick up some more patches in the next revision, maybe it
> would be more obvious why I'd like to get R/O support.

I'll try to take a look.

Johan