On Wed, Feb 19, 2020 at 10:30:50AM -0600, Tyler Hicks wrote: > On 2020-02-18 17:42:18, Brian Kubisiak wrote: > > Hi Tyler, > > > > > Can you elaborate some on the use case you have? > > > > On many modern embedded SoCs, there are multiple implementations of the same > > crypto algorithm---usually a CPU-based implementation using ISA extensions and a > > "security engine" implementation that implements crypto primitives on dedicated > > silicon. There are a few tradeoffs involved (performance, CPU overhead, > > resistance to side-channels attacks, etc), so it is not always clear which > > implementation is best. > > > > An SoC that I've been working on has both the CPU implementation and the > > security engine implementation of the cbc(aes) algorithm at the same priority, > > so the one picked to perform the encryption for a given ecryptfs mount is > > somewhat random. > > Have you looked into the possibility of increasing the priority of the > implementation that you prefer on your SoC? > > If that's not feasible, have you considered blacklisting the module > providing the implementation that you don't prefer? > > > My intention with this patch is to be able to select which > > implementation gets used for the mount using the > > ecryptfs_cipher_driver option instead of having the kernel pick. > > I don't think allowing users to specify a cipher driver is a good idea. > eCryptfs has always assumed that the crypto subsystem knows best about > the ideal implementation of "cbc(aes)" and I believe that this is how > the crypto subsystem expects eCryptfs to make use of their API. > > In addition to the design objection above, I'm worried about users > shooting themselves in the foot with this mount option. For example, > "ecryptfs_cipher_driver=ecb_aes_aesni" and > "ecryptfs_cipher_driver=xts_aes_aesni" are accepted. eCryptfs is only > implemented to operated in a (modified) CBC mode and letting users force > their way into using anything else is dangerous/insecure. > > Lets see if we can address your problem in the crypto subsystem (or with > the module blacklist) rather than creating this amount of flexibility in > eCryptfs. > > Tyler CRYPTO_MSG_UPDATEALG in the crypto_user configuration API can be used to change the priority of a crypto algorithm at runtime. It would need to be done before mounting eCryptfs. - Eric
