linux-kernel - Re: [PATCH 6/7] firmware: tee_bnxt: use tee_shm_alloc_kernel

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 9 Jun 2021 09:58:11 -0500
From:   Tyler Hicks <tyhicks@...ux.microsoft.com>
To:     Jens Wiklander <jens.wiklander@...aro.org>
Cc:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        op-tee@...ts.trustedfirmware.org,
        Sumit Garg <sumit.garg@...aro.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Sasha Levin <sashal@...nel.org>,
        Thirupathaiah Annapureddy <thiruan@...rosoft.com>,
        Vikas Gupta <vikas.gupta@...adcom.com>,
        "David S . Miller" <davem@...emloft.net>
Subject: Re: [PATCH 6/7] firmware: tee_bnxt: use tee_shm_alloc_kernel_buf()

On 2021-06-09 12:23:23, Jens Wiklander wrote:
> Uses the new simplified tee_shm_alloc_kernel_buf() function instead of
> the old deprecated tee_shm_alloc() function which required specific
> TEE_SHM-flags.
> 
> Signed-off-by: Jens Wiklander <jens.wiklander@...aro.org>

Since this series is essentially a rewrite of the shm allocation logic,
it is worth pointing out that the rewrite still uses contiguous
allocations (from alloc_pages()). The tee_bnxt_fw driver is performing
an order-10 allocation which is the max, by default. I've only tested
tee_bnxt_fw when it was built-in to the kernel and tee_bnxt_fw_probe()
was called early in boot but I suspect that it might not succeed when
built as a module and loaded later after memory is segmented. I think
this driver would benefit from being able to request a non-contiguous
allocation.

Is this rewrite a good time to offer drivers a way to perform a
non-contiguous allocation?

Tyler

> ---
>  drivers/firmware/broadcom/tee_bnxt_fw.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/firmware/broadcom/tee_bnxt_fw.c b/drivers/firmware/broadcom/tee_bnxt_fw.c
> index ed10da5313e8..56d00ddd4357 100644
> --- a/drivers/firmware/broadcom/tee_bnxt_fw.c
> +++ b/drivers/firmware/broadcom/tee_bnxt_fw.c
> @@ -212,10 +212,9 @@ static int tee_bnxt_fw_probe(struct device *dev)
>  
>  	pvt_data.dev = dev;
>  
> -	fw_shm_pool = tee_shm_alloc(pvt_data.ctx, MAX_SHM_MEM_SZ,
> -				    TEE_SHM_MAPPED | TEE_SHM_DMA_BUF);
> +	fw_shm_pool = tee_shm_alloc_kernel_buf(pvt_data.ctx, MAX_SHM_MEM_SZ);
>  	if (IS_ERR(fw_shm_pool)) {
> -		dev_err(pvt_data.dev, "tee_shm_alloc failed\n");
> +		dev_err(pvt_data.dev, "tee_shm_alloc_kernel_buf failed\n");
>  		err = PTR_ERR(fw_shm_pool);
>  		goto out_sess;
>  	}
> -- 
> 2.31.1
>