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: <072b3df6-09fb-98a8-2b58-41dfcabd98c0@gmail.com>
Date:   Sun, 27 Aug 2023 23:53:08 +0200
From:   Maximilian Luz <luzmaximilian@...il.com>
To:     Trilok Soni <quic_tsoni@...cinc.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/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.

>> +	depends on QCOM_QSEECOM
>> +	depends on EFI
>> +	help
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ