On Thu, Dec 26, 2024 at 12:26:29PM +0100, Lukas Wunner wrote: > 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. Nope, you need to get that old api back. Kernel virtual address space mappings for dma-buf are very intentionally optional. -Sima -- Simona Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
