> > Indeed, since v5.1, testmgr tests scatterlist elements that cross a > > page. > > However, the pages are guaranteed to be *physically* contiguous. > Does > > dma_map_sg() not handle this? > > > I'm not entirely sure and the API documentation is not particularly > clear on *what* dma_map_sg() actually does, but I highly doubt it > considering the particle count is only an input parameter (i.e. it > can't output an increase in particles that would be required). > So I think it just ensures the pages are actually flushed to memory > and accessible by the device (in case an IOMMU interferes) and not > much than that. > > In any case, scatter particles to be used by hardware should *not* > cross any physical page boundaries. > But also see the thread I had on this with Ard - seems like the crypto > API already has some mechanism for enforcing this but it's not enabled > for AEAD ciphers? > > > > > BTW, this isn't just a theoretical case. Many crypto API users do > > crypto on > > kmalloced buffers, and those can cross a page boundary, especially if > > they are > > large. All software crypto algorithms handle this case. > > > Software sits behind the CPU's MMU and sees virtual memory as > contiguous. It does not need to "handle" anything, it gets it for free. > Hardware does not have that luxury, unless you have a functioning IOMMU > but that is still pretty rare. > So for hardware, you need to break down your buffers until individual > pages and stitch those together. That's the main use case of a scatter > list and it requires the particles to NOT cross physical pages. > > > The fact that these types of issues are just being considered now > > certainly > > isn't raising my confidence in the hardware crypto drivers in the > > kernel... > > > Actually, this is *not* a problem with the hardware drivers. It's a > problem with the API and/or how you are trying to use it. Hardware > does NOT see the nice contiguous virtual memory that SW sees. > > If the driver may expect to receive particles that cross page > boundaries - if that's the spec - fine, but then it will have to > break those down into individual pages by itself. However, whomever > created the inside-secure driver was under the impression that this > was not supposed to be the case. And I don't know who's right or > wrong there, but from a side discussion with Ard I got the impression > that the Crypto API should fix this up before it reaches the driver. > Long story short: testmgr appears to be doing nothing wrong AND the driver appears to be doing nothing wrong, but it seems like there's a bug in the Crypto API itself with the scatter walk for AEAD ciphers. Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Inside Secure
