Re: [PATCH] security/keys: rewrite big_key crypto to use Zinc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, May 1, 2020 at 6:14 PM Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
>
> On Fri, May 01, 2020 at 06:06:17PM -0600, Jason A. Donenfeld wrote:
> > Hey Eric,
> >
> > Thanks for the review.
> >
> > I'll add `select CONFIG` as you suggested. I agree about trying to
> > move as much as possible out of crypto and into lib/crypto. Breaking
> > those dependency cycles won't be easy but perhaps it'll be possible to
> > chip away at that gradually. (I'd also lib a
> > lib/crypto/arch/{arch}/..., but I guess that's a separate discussion.)
> >
> > I'll also change -EINVAL to -EBADMSG. Nice catch.
> >
> > Regarding the buffer zeroing... are you sure? These buffers are
> > already being copied into filesystem caches and all sorts of places
> > over which we have zero control. At that point, does it matter? Or do
> > you argue that because it's still technically key material, we should
> > zero out both the plaintext and ciphertext everywhere we can, and
> > hopefully at some point the places where we can't will go away? IOW,
> > I'm fine doing that, but would like to learn your explicit reasoning
> > before.
>
> It's true that the buffer zeroing doesn't matter in big_key_preparse() because
> the buffer only holds the encrypted key (which is what the shmem file will
> contain).  But in big_key_read(), the buffer holds the decrypted key.  So it's
> at least needed there.  Having it in both places for consistency might be a good
> idea.

Alright. v2 coming your way shortly.


Jason



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux