Re: [PATCH] lib/crypto: powerpc/md5: Drop powerpc optimized MD5 code

["Christophe Leroy (CS GROUP)" <chleroy@kernel.org>]

Le 04/05/2026 à 15:56, Ard Biesheuvel a écrit :
> Hello Christophe,
> 
> On Mon, 4 May 2026, at 15:28, Christophe Leroy (CS GROUP) wrote:
> ...
>> I'm really concerned with the optimised MD5 going away now, and I'm also
>> wondering what will be the way to splice a file into the kernel and get
>> it's MD-5 hash from the TALITOS if AF_ALG goes away in medium-term.
>>
>> What is the way forward ? I'm open to any suggestion as I really can't
>> see where to go for now.
>>
> 
> AF_ALG was created to give user space access to crypto accelerators that
> require privileged execution, for sharing between clients, and for managing
> DMA etc.
> 
> The fact that kernel crypto code that does not have this requirement was
> exposed via AF_ALG too is a historical accident, and this is causing the
> pain that Eric describes wrt attack surface etc.
> 
> It sounds like you have constructed a vertically integrated system where
> the kernel provides the fallback when the Talitos engine is not available
> via AF_ALG.
> 
> This fallback does not need to live in the kernel, and it would be much
> better (as well as more efficient) if user space would implemented MD5
> itself if the Talitos cannot be accessed via AF_ALG. In user space, you
> can use any implementation you like, generic or asm accelerated. This is
> what all other architectures already implement, in OpenSSL etc.
> 
> Claiming that your user space software must only implement one code path,
> and that punting this to the kernel is therefore required is not a
> technical argument: this is just policy on your part that the community
> is not bound to.
> 
> However, deprecating AF_ALG does not mean that we will ever be able to
> remove it entirely. Especially the crypto accelerators that cannot be
> accessed by user space in any other way will remain supported as long
> as needed for legacy use cases.
> 
> But I think we should consider libkcapi as a general purpose crypto
> library deprecated too, as well as any other use of AF_ALG in lieu of
> user space libraries. It is not the kernel's job to execute user space
> code that can easily execute non-privileged as well.
> 
> I suppose there will be more discussion soon about AF_ALG deprecation
> for software crypto. It is likely that we will need to come up with
> an allowlist of algorithms, in order to limit the attack surface to those
> algorithms (such as your MD5) that are known to be relied upon by user space,
> rather than any random combination of all the buggy template code and
> null_ciphers etc.
> 
> Do you have any use cases where MD5 is a bottle neck, and the generic
> implementation is too slow?

Well, our boards are used in air trafic control voice communication 
systems, every millisecond is worth it and every performance degradation 
must be explained, justified, etc ....

Christophe