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] [day] [month] [year] [list]

Message-ID: <aF6Lq8EFEsyeJ0Ma@hovoldconsulting.com>
Date: Fri, 27 Jun 2025 14:16:43 +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 Fri, Jun 27, 2025 at 02:09:51AM +0300, Dmitry Baryshkov wrote:
> On Thu, Jun 26, 2025 at 03:13:42PM +0200, Johan Hovold wrote:

> > Furthermore, getting an allocated block of addresses in SDAM for Linux
> > could be useful for other things too.
> 
> Yes, but this obviously can't happen for released platforms.

We managed to get one for sc8280xp post release (was harder for x1e for
some reason).

> > > > > 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.
> > > 
> > > For me it provided a better user experience. Yes, I'm using C630 from
> > > time to time, including the kernel development. A drifted but ticking
> > > RTC is better than the RTC that rolls backs by several months at a
> > > reboot, because of the missing RTC offset info.
> > 
> > Does it have to roll back? Can't you just keep it running after whatever
> > semi-random date it started at?
> 
> It rolls back after reboot.

That's odd. Doesn't happen here with the X1E CRD if I drop the uefi
offset property in DT. I'm back in the seventies but time is strictly
increasing also after reboots.

Perhaps you have some user space setting that resets it?

> > And there is ntp and services like
> > fake-hwclock which saves the time on shutdown too.
> 
> Likewise I can plug in the USB RTC or do something else. NTP requires
> network access, which is fun to have if you are debugging modem of WiFi.
>
> > Anyway, I still do no understand why you seem so reluctant to having a
> > proper functioning RTC using an SDAM offset.
> 
> Because that would be a one-off solution for this particular laptop,
> etc. I want something that other laptops can use without having to find
> another magic value which suits a particular laptop instance.

My point is that it's not really a solution. These machines still do not
have persistent UEFI variables, and now they have an apparently
functional but still broken RTC.

I added support for the UEFI offset to the driver so that the time could
be set on Qualcomm machines. With this series that is still not the
case, even if people may now initially get the impression that it works
since the time is only off by a few seconds (until it becomes minutes
and hours and you starting missing your trains).

Johan