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]
Date:   Wed, 28 Jun 2023 14:50:46 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Maximilian Luz <luzmaximilian@...il.com>
Cc:     Bjorn Andersson <andersson@...nel.org>,
        Andy Gross <agross@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Ilias Apalodimas <ilias.apalodimas@...aro.org>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Sudeep Holla <sudeep.holla@....com>,
        Steev Klimaszewski <steev@...i.org>,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 3/4] firmware: qcom_scm: Add support for Qualcomm
 Secure Execution Environment SCM interface

On Wed, Jun 28, 2023 at 02:11:07PM +0200, Johan Hovold wrote:
> On Mon, May 29, 2023 at 01:03:50AM +0200, Maximilian Luz wrote:

> > @@ -1496,6 +1903,12 @@ static int qcom_scm_probe(struct platform_device *pdev)
> >  
> >  	__get_convention();
> >  
> > +	ret = qcom_scm_qseecom_init();
> > +	if (ret < 0) {
> > +		__scm = NULL;
> 
> So as I mentioned in my reply to 2/4, you can still have clients
> registered here when you clear the __scm pointer which they rely on
> after an error.
> 
> Not sure how best to handle this, but perhaps registering a qseecom
> platform device here and have it's driver probe defer until scm is
> available would work?
> 
> That way you could also separate out the qseecom implementation in a
> separate file (driver) rather than having the ifdef above.

An alternative may be to just warn and continue if
qcom_scm_qseecom_init() fails. It should never return -EPROBE_DEFER
anyway, right?

Johan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ