linux-kernel - Re: [PATCH v2] firmware: qcom_scm: Add a padded page to ensure DMA memory from lower 4GB

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]

Message-ID: <d85bf913-b6dc-e9fd-7c54-fe52b79c2593@quicinc.com>
Date: Wed, 29 May 2024 17:24:29 +0530
From: Mukesh Ojha <quic_mojha@...cinc.com>
To: Bjorn Andersson <andersson@...nel.org>
CC: <konrad.dybcio@...aro.org>, <linux-arm-msm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] firmware: qcom_scm: Add a padded page to ensure DMA
 memory from lower 4GB



On 5/27/2024 2:16 AM, Bjorn Andersson wrote:
> On Fri, May 24, 2024 at 09:01:45PM GMT, Mukesh Ojha wrote:
>> For SCM protection, memory allocation should be physically contiguous,
>> 4K aligned, and non-cacheable to avoid XPU violations. This granularity
>> of protection applies from the secure world. Additionally, it's possible
>> that a 32-bit secure peripheral will access memory in SoCs like
>> sm8{4|5|6}50 for some remote processors. Therefore, memory allocation
>> needs to be done in the lower 4 GB range. To achieve this, Linux's CMA
>> pool can be used with dma_alloc APIs.
>>
>> However, dma_alloc APIs will fall back to the buddy pool if the requested
>> size is less than or equal to PAGE_SIZE. It's also possible that the remote
>> processor's metadata blob size is less than a PAGE_SIZE. Even though the
>> DMA APIs align the requested memory size to PAGE_SIZE, they can still fall
>> back to the buddy allocator, which may fail if `CONFIG_ZONE_{DMA|DMA32}`
>> is disabled.
> 
> Does "fail" here mean that the buddy heap returns a failure - in some
> case where dma_alloc would have succeeded, or that it does give you
> a PAGE_SIZE allocation which doesn't meeting your requirements?

Yes, buddy will also try to allocate memory and may not get PAGE_SIZE 
memory in lower 4GB(for 32bit capable device) if CONFIG_ZONE_{DMA|DMA32} 
is disabled. However, DMA memory would have successful such case if
padding is added to size to cross > PAGE_SIZE.

> 
>  From this I do find the behavior of dma_alloc unintuitive, do we know if
> there's a reason for the "equal to PAGE_SIZE" case you describe here?

I am not a memory expert but the reason i can think of could be, <= 
PAGE_SIZE can anyway possible to be requested outside DMA coherent api's
with kmalloc and friends api and that could be the reason it is falling
back to buddy pool in DMA api.

-Mukesh