On Thu, Dec 26, 2024 at 11:29:23AM +0530, Sumit Garg wrote: > On Tue, 24 Dec 2024 at 14:58, Lukas Wunner <lukas@xxxxxxxxx> wrote: > > However in the case of restricted memory, the situation is exactly > > the opposite: The kernel may *not* be able to access the data, > > but the crypto accelerator can access it just fine. > > > > I did raise a concern about this to the maintainer, but to no avail: > > https://lore.kernel.org/r/Z1Kym1-9ka8kGHrM@xxxxxxxxx/ > > Herbert's point is valid that there isn't any point for mapping > restricted memory in the kernel virtual address space as any kernel > access to that space can lead to platform specific hardware error > scenarios. And for that reason we simply disallow dma_buf_mmap() and > don't support dma_buf_vmap() for DMA-bufs holding TEE restricted > memory. The API for signature generation/verification (e.g. crypto_sig_sign(), crypto_sig_verify()) no longer accepts scatterlists, only buffers in virtual address space: https://lore.kernel.org/all/ZIrnPcPj9Zbq51jK@xxxxxxxxxxxxxxxxxxx/ Hence in order to use buffers in restricted memory for signature generation/verification, you'd need to map them into virtual address space first. Thanks, Lukas
