linux-kernel - Re: [RFC PATCH 01/10] firmware: arm_scmi: Reset properly xfer SCMI status

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: <20210607180137.GB40811@e120937-lin>
Date:   Mon, 7 Jun 2021 19:01:37 +0100
From:   Cristian Marussi <cristian.marussi@....com>
To:     Sudeep Holla <sudeep.holla@....com>
Cc:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        james.quinlan@...adcom.com, Jonathan.Cameron@...wei.com,
        f.fainelli@...il.com, etienne.carriere@...aro.org,
        vincent.guittot@...aro.org, souvik.chakravarty@....com
Subject: Re: [RFC PATCH 01/10] firmware: arm_scmi: Reset properly xfer SCMI
 status

On Mon, Jun 07, 2021 at 06:38:09PM +0100, Sudeep Holla wrote:
> On Sun, Jun 06, 2021 at 11:12:23PM +0100, Cristian Marussi wrote:
> > When an SCMI command transfer fails due to some protocol issue an SCMI
> > error code is reported inside the SCMI message payload itself and it is
> > then retrieved and transcribed by the specific transport layer into the
> > xfer.hdr.status field by transport specific .fetch_response().
> > 
> > The core SCMI transport layer never explicitly reset xfer.hdr.status,
> > so when an xfer is reused, if a transport misbehaved in handling such
> > status field, we risk to see an invalid ghost error code.
> > 
> > Reset xfer.hdr.status to SCMI_SUCCESS right before each transfer is
> > started.
> >
> 
> Any particular reason why it can't be part of xfer_get_init which has other
> initialisations ? If none, please move it there.
> 

Well it was there initially then I moved it here.

The reason is mostly the same as the reason for the other patch in this
series that adds a reinit_completion() in this same point: the core does
not forbid to reuse an xfer multiple times, once obtained with xfer_get()
or xfer_get_init(), and indeed some protocols do such a thing: they
implements such do_xfer looping and bails out on error.

In the way that it is implemented now in protocols poses no problem
indeed because the do_xfer loop bails out on error and the xfer is put,
but as soon as some protocol is implemented that violates this common
practice and it just keeps on reuse an xfer after an error fo other
do_xfers() this breaks...so it seemed more defensive to just reinit the
completion and the status before each send.

Thanks,
Cristian

> -- 
> Regards,
> Sudeep