On Mon, 2016-12-05 at 20:34 +0800, Herbert Xu wrote: > On Fri, Dec 02, 2016 at 04:15:21PM -0800, Tim Chen wrote: > > > > Algorithms not compatible with mcryptd could be spawned by mcryptd > > with a direct crypto_alloc_tfm invocation using a "mcryptd(alg)" > > name construct. This causes mcryptd to crash the kernel if > > "alg" is incompatible and not intended to be used with mcryptd. > > > > A flag CRYPTO_ALG_MCRYPT is being added to mcryptd compatible > > algorithms' cra_flags. The compatability is checked when mcryptd spawn > > off an algorithm. > > > > Link: http://marc.info/?l=linux-crypto-vger&m=148063683310477&w=2 > > Cc: sta...@vger.kernel.org > > Reported-by: Mikulas Patocka <mpato...@redhat.com> > > Tested-by: Megha Dey <megha....@linux.intel.com> > > Signed-off-by: Tim Chen <tim.c.c...@linux.intel.com> > Tim, I think we should instead make mcryptd refuse to generate > a non-internal algorithm. This way the user would not be able > to access it at all since they can only request for non-internal > algorithms. > > Basically you want to check at the start of mcryptd_create_hash > that the INTERNAL bit is set on both the type and mask as returned > by crypto_get_attr_type.
I have thought about that. However, not all internal algorithms are compatible with mcryptd. We can still have trouble if some random internal algorithm is paired with mcryptd. Tim -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
