linux-kernel - Re: [PATCH 3/4] 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: <66f076ae-a9b5-f595-a88d-ede66a7e8e89@gmail.com>
Date:   Tue, 17 Jan 2023 13:07:24 +0100
From:   Maximilian Luz <luzmaximilian@...il.com>
To:     Johan Hovold <johan@...nel.org>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Steev Klimaszewski <steev@...i.org>,
        Shawn Guo <shawn.guo@...aro.org>,
        Sudeep Holla <sudeep.holla@....com>,
        Cristian Marussi <cristian.marussi@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-arm-msm@...r.kernel.org, linux-efi@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/4] firmware: Add support for Qualcomm UEFI Secure
 Application

On 1/17/23 12:05, Johan Hovold wrote:
> On Sun, Jul 24, 2022 at 12:49:48AM +0200, Maximilian Luz wrote:
>> On platforms using the Qualcomm UEFI Secure Application (uefisecapp),
>> EFI variables cannot be accessed via the standard interface in EFI
>> runtime mode. The respective functions return EFI_UNSUPPORTED. On these
>> platforms, we instead need to talk to uefisecapp. This commit provides
>> support for this and registers the respective efivars operations to
>> access EFI variables from the kernel.
>>
>> Communication with uefisecapp follows the standard Qualcomm Trusted
>> Environment (TEE or TrEE) / Secure OS conventions via the respective SCM
>> call interface. This is also the reason why variable access works
>> normally while boot services are active. During this time, said SCM
>> interface is managed by the boot services. When calling
>> ExitBootServices(), the ownership is transferred to the kernel.
>> Therefore, UEFI must not use that interface itself (as multiple parties
>> accessing this interface at the same time may lead to complications) and
>> cannot access variables for us.
>>
>> Signed-off-by: Maximilian Luz <luzmaximilian@...il.com>
>> ---
> 
>> +static int qcom_uefisecapp_probe(struct platform_device *pdev)
>> +{
>> +	struct qcuefi_client *qcuefi;
>> +	int status;
> 
> [...]
> 
>> +	/* Set up kobject for efivars interface. */
>> +	qcuefi->kobj = kobject_create_and_add("qcom_tee_uefisecapp", firmware_kobj);
>> +	if (!qcuefi->kobj) {
>> +		status = -ENOMEM;
>> +		goto err_kobj;
> 
> When preparing some related EFI patches, I noticed that the error labels
> here are named after where you jump from rather than after what they do
> (as is suggested by the coding standard).
> 
> Would you mind changing that (throughout) for your v2?

Not at all. Will change that for v2.

Regards,
Max

>> +	}
>> +
>> +	/* Register global reference. */
>> +	platform_set_drvdata(pdev, qcuefi);
>> +	status = qcuefi_set_reference(qcuefi);
>> +	if (status)
>> +		goto err_ref;
>> +
>> +	/* Register efivar ops. */
>> +	status = efivars_register(&qcuefi->efivars, &qcom_efivar_ops, qcuefi->kobj);
>> +	if (status)
>> +		goto err_register;
>> +
>> +	return 0;
>> +
>> +err_register:
>> +	qcuefi_set_reference(NULL);
>> +err_ref:
>> +	kobject_put(qcuefi->kobj);
>> +err_kobj:
>> +	qctee_dma_free(qcuefi->dev, &qcuefi->dma);
>> +	return status;
>> +}
> 
> Johan