Re: [Linux-ima-user] evm: runaway loop in verify_signature() produce deadlock in process_measurement().

[Mimi Z. <zo...@li...>]

On Tue, 2017-01-03 at 21:00 +0300, Mikhail Kurinnoi wrote:
> В Tue, 03 Jan 2017 10:55:37 -0500
> Mimi Zohar <zo...@li...> пишет:
> 
> > On Tue, 2017-01-03 at 18:02 +0300, Mikhail Kurinnoi wrote:
> > > В Tue, 03 Jan 2017 08:42:50 -0500
> > > Mimi Zohar <zo...@li...> пишет:
> > >   
> > > > On Mon, 2017-01-02 at 23:34 +0300, Mikhail Kurinnoi wrote:  
> > > > > I switched my tests on another disk and faced with deadlock
> > > > > during boot. The deadlock are reproducible if EVM enabled and
> > > > > EVM x509 cert is loaded in kernel code (CONFIG_EVM_LOAD_X509)
> > > > > with default IMA policy.    
> > > > 
> > > > These build configuration options are designed to be used in an
> > > > environment with a signed init.  If you're not interested in
> > > > appraising the init, then wait until you're ready to load the
> > > > keys.  
> > > 
> > > I have this issue if I load cert and EVM keys from initramfs by
> > > script with CONFIG_EVM_LOAD_X509 disabled in kernel.
> > > 
> > > I have no issue with EVM digital signature or HMAC during boot or
> > > after boot, I faced with deadlock on switch root only because kernel
> > > want to check what crypto-related kernel modules I have installed on
> > > real root with /bin/kmod, but, since /bin/kmod also was signed by
> > > EVM digital signature, and I could have crypto-related kernel
> > > modules installed in real root, kernel call /bin/kmod one more
> > > time, but we already have this inode locked in
> > > process_measurement()...  
> > 
> > I lost you here...  If the EVM and IMA keys used to verify /bin/kmod
> > are loaded onto their respective keyrings, then there shouldn't be a
> > problem.  The verification status result of the first /bin/kmod would
> > be cached.
> 
> Mimi, the issue not connected to EVM and IMA keys and certs. They all
> are loaded onto their respective keyrings for sure. Moreover, this
> issue not connected directly to IMA or EVM at all. This is all about 
> kernel crypto work, that EVM, probably, should take into account.
> 
> What I am trying to explain in another form:
> 0) IMA/EVM fully loaded and fully functional. Switch to real root.
> 1) Kernel(IMA/EVM) trying to verify /sbin/init EVM digital signature, call
> verify_signature().
> 2) Kernel(crypto) see rsa+sha1.
> 3) Kernel(crypto) know, we could have 3 sha1 modules.
> 4) Kernel(crypto) ask "what sha1 kernel modules we have installed into
> system" and call /bin/kmod.
> 5) Kernel(IMA/EVM) trying to verify /bin/kmod EVM digital signature, call
> verify_signature().
> 6) Kernel(crypto) see rsa+sha1.
> 7) Kernel(crypto) know, we could have 3 sha1 modules.
> 8) Kernel(crypto) ask "what sha1 modules we have installed into system"
> and call /bin/kmod.
> 9) Kernel(IMA/EVM) trying to verify /bin/kmod EVM digital signature, wait, 
> we already lock /bin/kmod inode in p5.
> 
> In my case, kernel have all 3 modules built-in:
> CONFIG_CRYPTO_SHA1=y
> CONFIG_CRYPTO_SHA1_SSSE3=y
> CONFIG_CRYPTO_SHA1_MB=y
> but kernel will use /bin/kmod to check installed into system kernel modules 
> any way.

It makes no sense to call kmod to load the crypto kernel modules if
they're builtin.  Out of curiosity, are you also seeing this problem if
only "CONFIG_CRYPTO_SHA1" is enabled?

> This is first verification for /bin/kmod, so, no cache for /bin/kmod
> yet. We just now changed the root, we don't have any cache for inodes
> in this partition, this is the problem. We can't use /bin/kmod before
> EVM verification and we can't verify /bin/kmod EVM signature, since we
> need /bin/kmod already verified for this.

A temporary fix for now would be to access /sysroot/bin/kmod from the
initramfs.

Mimi