public inbox for linux-integrity@vger.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Matthias Gerstner <mgerstner@suse.de>
Cc: linux-integrity@vger.kernel.org,
	Mikhail Kurinnoi <viewizard@viewizard.com>
Subject: Re: IMA: Deadlock in ima_appraise_measurement when /bin/kmod carries a digsig in security.evm
Date: Fri, 22 Jun 2018 15:48:48 -0400	[thread overview]
Message-ID: <1529696928.3418.16.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180620105351.GA8033@f195.suse.de>

On Wed, 2018-06-20 at 12:53 +0200, Matthias Gerstner wrote:
> Hello Mimi,
> 
> > Somehow I missed it.  A more generic patch is currently queued, which
> > should resolve this problem as well.  Please try commit fdc33c29b022
> > ("evm: Don't deadlock if a crypto algorithm is unavailable") in the
> > next-integrity-queued branch.
> 
> thank you for helping me out. I tried that patch but it does no fix the
> issue completely. It still ends up in a deadlock. As you can see from
> the backtrace attached below the call to public_key_verify_signature()
> still causes a deadlock, since there is the following call in it:
> 
>     tfm = crypto_alloc_akcipher(alg_name, 0, 0);
> 
> Passing CRYPTO_NOLOAD here does fix the deadlock for me, but I fear that
> won't be an option and the interface needs to be extended to pass flags?

I'm having a hard time reproducing this bug.  Too many different
permutations of EVM/IMA keys, signatures, and kernel modules.  Is the
problem loading the crypto algorithm, itself, built as a kernel module
(eg. insmod/modprobe - If so, which syscall is being used?)  Or is the
problem accessing a file signed by an algorithm built as a kernel
module.

Mikhail, I'm really sorry for not seeing the patch.  I must have been
dropped from the sf mailing list and didn't notice.  I was only seeing
posts when Cc'ed on them.

Matthias, does Mikhail's patch fix this problem?

Mimi

> 
> Regards
> 
> Matthias
> 
> --
> 
> kgdb backtrace of deadlock situation:
> 
> #0  public_key_verify_signature (pkey=0xffff88013a8ef852, sig=0xffff88013a8ef910) at crypto/asymmetric_keys/public_key.c:100
> #1  0xffffffff813b0e4a in asymmetric_verify (keyring=<optimized out>, sig=<optimized out>, siglen=<optimized out>, 
>     data=0xffff88013a8ef9d4 "\334'e-\203\071m>\312@xm\242\311r2\017\212\207\230", datalen=20) at security/integrity/digsig_asymmetric.c:113
> #2  0xffffffff813b0c9f in integrity_digsig_verify (id=<optimized out>, sig=<optimized out>, siglen=<optimized out>, digest=<optimized out>, 
>     digestlen=<optimized out>) at security/integrity/digsig.c:75
> #3  0xffffffff813b5c51 in evm_verify_hmac (dentry=0xffff88013a8ef852, xattr_name=0xffffffff8200faf5 "security.ima", 
>     xattr_value=0xffff88013b14db80 "\004\004Z\361\316\062\353\001\037g\210A\260C9>\247\006\001dN`\241#\037\344\301\301\rq%\025", xattr_value_len=0, 
>     iint=0x1 <irq_stack_union+1>) at security/integrity/evm/evm_main.c:178
> #4  0xffffffff813b5f11 in evm_verifyxattr (dentry=<optimized out>, xattr_name=<optimized out>, xattr_value=<optimized out>, xattr_value_len=<optimized out>, 
>     iint=<optimized out>) at security/integrity/evm/evm_main.c:264
> #5  0xffffffff813b55b6 in ima_appraise_measurement (func=<optimized out>, iint=0xffff880138774960, file=<optimized out>, filename=<optimized out>, 
>     xattr_value=0xffff88013b14db80, xattr_len=<optimized out>, opened=2) at security/integrity/ima/ima_appraise.c:243
> #6  0xffffffff813b1ce3 in process_measurement (file=0xffff880137dc0300, cred=<optimized out>, secid=<optimized out>, buf=<optimized out>, 
>     size=<optimized out>, mask=<optimized out>, func=FILE_CHECK, opened=<optimized out>) at security/integrity/ima/ima_main.c:301
> #7  0xffffffff813b1df6 in ima_file_check (file=0xffff880137dc0300, mask=<optimized out>, opened=2) at security/integrity/ima/ima_main.c:396
> #8  0xffffffff811a7675 in do_last (opened=<optimized out>, op=<optimized out>, file=<optimized out>, nd=<optimized out>) at fs/namei.c:3372
> #9  path_openat (nd=0xffff88013a8efd30, op=<optimized out>, flags=<optimized out>) at fs/namei.c:3505
> #10 0xffffffff811a7827 in do_filp_open (dfd=<optimized out>, pathname=<optimized out>, op=0xffff88013a8efe54) at fs/namei.c:3540
> #11 0xffffffff8119ff83 in do_open_execat (fd=<optimized out>, name=0xffff88013a83b000, flags=<optimized out>) at fs/exec.c:854
> #12 0xffffffff811a02b6 in do_execveat_common (fd=-100, filename=<optimized out>, flags=<optimized out>, argv=..., envp=...) at fs/exec.c:1755
> #13 0xffffffff811a0788 in do_execve (filename=<optimized out>, __argv=<optimized out>, __envp=<optimized out>) at fs/exec.c:1862
> #14 0xffffffff811a094b in __do_sys_execve (envp=<optimized out>, argv=<optimized out>, filename=<optimized out>) at fs/exec.c:1943
> #15 __se_sys_execve (envp=<optimized out>, argv=<optimized out>, filename=<optimized out>) at fs/exec.c:1938
> #16 __x64_sys_execve (regs=<optimized out>) at fs/exec.c:1938
> #17 0xffffffff8100130e in do_syscall_64 (nr=<optimized out>, regs=0xffff88013a8eff58) at arch/x86/entry/common.c:287
> #18 0xffffffff81a00088 in entry_SYSCALL_64 () at arch/x86/entry/entry_64.S:238
> #19 0x0000000000000000 in ?? ()
> 
> (gdb) info locals
> 
> cwait = {completion = {done = 982448596, wait = {lock = {{rlock = {raw_lock = {val = {counter = 20}}}}}, head = {next = 0x200 <irq_stack_union+512>,
>         prev = 0xffff880138779009}}}, err = 982448544}
> tfm = <optimized out>
> sig_sg = {page_link = 0, offset = 0, length = 0, dma_address = 0, dma_length = 0}
> digest_sg = {page_link = 0, offset = 2172746197, length = 4294967295, dma_address = 0, dma_length = 2174749206}
> alg_name = 0xffff88013a8ef840 "pkcs1pad(rsa,sha1)"
> alg_name_buf = "pkcs1pad(rsa,sha1)\0<...>"

  reply	other threads:[~2018-06-22 19:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-18 14:56 IMA: Deadlock in ima_appraise_measurement when /bin/kmod carries a digsig in security.evm Matthias Gerstner
2018-06-19 22:21 ` Mimi Zohar
2018-06-20 10:53   ` Matthias Gerstner
2018-06-22 19:48     ` Mimi Zohar [this message]
2018-06-24 22:31       ` Mimi Zohar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1529696928.3418.16.camel@linux.vnet.ibm.com \
    --to=zohar@linux.vnet.ibm.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=mgerstner@suse.de \
    --cc=viewizard@viewizard.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox