linux-kernel - Re: [PATCH v6 3/3] firmware: Add support for Qualcomm UEFI Secure Application

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: <89294acf-501f-5c2c-1619-cfc2b3dc893a@quicinc.com>
Date:   Sun, 27 Aug 2023 14:59:54 -0700
From:   Trilok Soni <quic_tsoni@...cinc.com>
To:     Maximilian Luz <luzmaximilian@...il.com>,
        Bjorn Andersson <andersson@...nel.org>
CC:     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>,
        Johan Hovold <johan@...nel.org>,
        Steev Klimaszewski <steev@...i.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        Johan Hovold <johan+linaro@...nel.org>
Subject: Re: [PATCH v6 3/3] firmware: Add support for Qualcomm UEFI Secure
 Application

On 8/27/2023 2:53 PM, Maximilian Luz wrote:
> On 8/27/23 23:26, Trilok Soni wrote:
>> On 8/27/2023 2:14 PM, Maximilian Luz wrote:
>>>   +config QCOM_QSEECOM_UEFISECAPP
>>> +    bool "Qualcomm SEE UEFI Secure App client driver"
>>
>> Why not "tristate"? This driver can be a loadable module, right?
> 
> As I understand, modular efivars have still not been fully sorted out in
> the kernel. For example, userspace could try and mount efivarfs before
> the module has been loaded and by that erroneously determine that the
> system doesn't support efivars. So requiring it to be built in for now
> is more of a workaround (which has been suggested by Johan Hovold).
> 
> There is no technical limitation in this part of the code itself, so
> enabling it (and QCOM_QSEECOM for that matter) to be built as module
> should be fairly straightforward once that's been sorted out.

If not this application I would atleast like the QSEECOM driver to be a loadable module due to GKI (Generic Kernel Image) needs. Can we mark QSEECOM as "tristate" please? If not then there is a problem which we are not solving right now as you are documenting above and just moving it it for future and downstream vendors will keep having their additional changes to make it fit for loadable module needs. 

-- 
---Trilok Soni