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: <c4ff0ea7-db2f-4a1a-a095-c3f8249d294a@arm.com>
Date: Tue, 13 Jan 2026 17:30:10 +0000
From: Andre Przywara <andre.przywara@....com>
To: Vedashree Vidwans <vvidwans@...dia.com>, salman.nabi@....com,
 sudeep.holla@....com, lpieralisi@...nel.org, mark.rutland@....com
Cc: ardb@...nel.org, chao.gao@...el.com,
 linux-arm-kernel@...ts.infradead.org, linux-coco@...ts.linux.dev,
 linux-kernel@...r.kernel.org, sdonthineni@...dia.com, vsethi@...dia.com,
 vwadekar@...dia.com
Subject: Re: [RFC PATCH 0/5] Arm LFA: Improvements and interrupt support

Hi Vedashree,

thanks for your efforts on this, and sorry for the delay on our side. We 
were hold up by a combination of spec changes and non-overlapping holidays.

On 08/12/2025 22:13, Vedashree Vidwans wrote:
> Hello,
> 
> The patches update the proposed Arm Live Firmware Activation (LFA)
> kernel driver [1] to incorporate review feedback [2] and refine the
> activation flow while remaining aligned with the LFA specification
> DEN0147 [3] and the SMCCC 1.2 calling convention. The series keeps
> the existing functionality but restructures and extends it to improve
> robustness, reviewability, and future extensibility.​

I would propose we change that approach a bit. We have updated and 
improved the driver internally, but were waiting for the new version of 
the spec (BET1) to be released, which happened some weeks ago. Salman 
will send out a new version of the driver in the next few days. Anything 
that is a bug (like the omission of the SMCCC v1.2 interface) will be 
addressed there, as there is no point to merge with a known buggy base 
patch. Also we will incorporate the changes we made so far, including 
adjustments for the new spec version.

Anything that can be added as independent patches should be done so, I 
think for instance the interrupt support is such a candidate. Ideally 
you can rebase your series on the changed base patch once this has been 
posted.
For other things like the platform driver introduction we can use your 
series here as a discussion base, as it allows us to reason and discuss 
this easier than by looking at a from-scratch patch.

Does this make sense?

Also please note that the DT and ACPI part has changed in the latest 
version of the spec. I will send a DT binding patch ASAP, to get this 
part out of the way.

Cheers,
Andre


 > > The SMCCC usage in the driver is updated to consistently use the
> SMCCC 1.2 register-based calling convention, consolidating arguments
> and results into a single struct to reduce stack usage and simplify
> the SMC interface. The patches also split the original changes into
> focused pieces and document the device node bindings in the commit
> messages, making it easier to follow and validate the implementation
> against the specification.​
> 
> The kernel driver is registered as a platform driver in accordence to
> the LFA device defined by the specification [3]. The driver now extends
> interface for interrupt-based enablement of LFA. During LFA, the
> interrupt
> thread refreshes firmware component details after each activation step
> and iterates over all activable components until no further activation
> is pending, matching the spec’s allowance for component detail changes
> after activation. This ensures that sysfs exposure of LFA components
> remains consistent with the authoritative information provided by the
> secure firmware.​
> 
> The handling of CPU rendezvous is adjusted so that the kernel now
> honors the rendezvous policy chosen by the firmware, instead of
> unconditionally forcing a rendezvous. This reflects experience with
> existing firmware deployments where mandatory rendezvous is not
> required, while still allowing the firmware to request it when
> needed.​
> 
> Thank you,
> Veda
> 
> [1] https://lore.kernel.org/lkml/20250926123145.268728-1-salman.nabi@arm.com/
> [2] https://lkml.org/lkml/2025/10/8/980
> [3] https://developer.arm.com/documentation/den0147/latest/
> 
> Vedashree Vidwans (5):
>    firmware: smccc: LFA: use smcc 1.2
>    firmware: smccc: LFA: refactor
>    firmware: smccc: add timeout, touch wdt
>    firmware: smccc: register as platform driver
>    firmware: smccc: lfa: refresh fw details
> 
>   drivers/firmware/smccc/Kconfig  |   3 +-
>   drivers/firmware/smccc/lfa_fw.c | 478 +++++++++++++++++++++++++-------
>   2 files changed, 380 insertions(+), 101 deletions(-)
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ