linux-kernel - Re: [PATCH] firmware: arm_scmi: add timeout in do_xfer_with

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: <D94LGXDHGVBD.1GB1GHOWORHMU@gmail.com>
Date: Sat, 12 Apr 2025 13:39:45 +0300
From: "Matthew Bystrin" <dev.mbstr@...il.com>
To: "Sudeep Holla" <sudeep.holla@....com>
Cc: "Cristian Marussi" <cristian.marussi@....com>,
 <arm-scmi@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
 <linux-arm-kernel@...ts.infradead.org>, "Philipp Zabel"
 <p.zabel@...gutronix.de>, "Peng Fan" <peng.fan@....com>
Subject: Re: [PATCH] firmware: arm_scmi: add timeout in
 do_xfer_with_response()

Sudeep,

Thanks for taking your time.

Sudeep Holla, Apr 09, 2025 at 14:12:
> The start update should retain as soon as Platform uC acks the request.
> And 2 notifications can be sent out for update procedure started and
> completed. I don't see any issue there. What is the semantics you are
> talking about ?

I'm going to refer to section 4.1.1 from the spec, where stated following about
delayed responses,

"Messages sent to indicate completion of the work that is associated with an
asynchronous command" 

Compared to notifications,

"These messages provide notifications of events taking place in the platform.
Events might include changes in power state, performance state, or other
platform status"

So before I implemented mentioned driver I had red this two and had chosen
delayed responses, because it had seemed more appropriate. Details below.

> Even delayed response as some timeout so I would rather prefer to use
> notifications

Hmm, I see.

> in your usecase as it is completely async.

Just to emphasize, according to the spec I don't think that delayed responses
and events have different degree of asynchrony. The difference is in the
initiator of 'messaging'. Events are sent by platform to indicate its' state and
delayed responses are sent to indicate status of previously requested operation.

I used the latter, because firmware update can't happen spontaneously. That what
I meant when used term 'semantics'.

> Yes neither per-transport nor per-protocol timeout will suffice in your case.
> This 10s timeout is specific to the update operation and hence use
> notification. All other solution is just workarounds not generic solution.
>
> -- 
> Regards,
> Sudeep

I see your point of view. However, taking into account given arguments, did I
convince you that delayed responses handling should be implemented in slightly
different way?

-- 
Best regards,
Matthew