linux-kernel - [PATCH v2 0/2] ima/evm: Ensure digest to verify is in linear mapping area

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20221201100625.916781-1-roberto.sassu@huaweicloud.com>
Date:   Thu,  1 Dec 2022 11:06:23 +0100
From:   Roberto Sassu <roberto.sassu@...weicloud.com>
To:     zohar@...ux.ibm.com, dmitry.kasatkin@...il.com,
        paul@...l-moore.com, jmorris@...ei.org, serge@...lyn.com
Cc:     linux-integrity@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Roberto Sassu <roberto.sassu@...wei.com>
Subject: [PATCH v2 0/2] ima/evm: Ensure digest to verify is in linear mapping area

From: Roberto Sassu <roberto.sassu@...wei.com>

As sg_set_buf() requires the buffer for a crypto operation to be in the
linear mapping area, so that it is always in adjacent pages, ensure that
this requirement is met for IMA/EVM.

Currently, evm_verify_hmac() and xattr_verify() put the evm_digest and
ima_max_digest_data structures in the stack. As normally the stack is in
the linear mapping area, passing them to sg_set_buf() would not be a
problem.

However, if CONFIG_VMAP_STACK is enabled, these structures will reside in
the vmalloc area instead. If CONFIG_DEBUG_SG is enabled, the kernel will
panic:

[  467.077359] kernel BUG at include/linux/scatterlist.h:163!
[  467.077939] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI

[...]

[  467.095225] Call Trace:
[  467.096088]  <TASK>
[  467.096928]  ? rcu_read_lock_held_common+0xe/0x50
[  467.097569]  ? rcu_read_lock_sched_held+0x13/0x70
[  467.098123]  ? trace_hardirqs_on+0x2c/0xd0
[  467.098647]  ? public_key_verify_signature+0x470/0x470
[  467.099237]  asymmetric_verify+0x14c/0x300
[  467.099869]  evm_verify_hmac+0x245/0x360
[  467.100391]  evm_inode_setattr+0x43/0x190

To overcome this problem, dynamically allocate the structures with
kmalloc() if CONFIG_VMAP_STACK is enabled, so that they are placed in the
linear mapping area, and use them instead of the in-stack counterparts.

A test report is available here:

https://github.com/robertosassu/ima-evm-utils/actions/runs/3590837109/jobs/6045608579

which contains the following test (include tests for EVM portable
signatures and IMA verity signatures):

https://github.com/robertosassu/ima-evm-utils/commit/41cf11d299e9fc2d13a60dce4b275c2675d9cc23

Changelog:

v1:
- Dynamically allocate the data structures in IMA and EVM, when necessary,
  instead of always making a copy in asymmetric_verify() (suggested by
  Mimi)

Roberto Sassu (2):
  evm: Alloc evm_digest in evm_verify_hmac() if CONFIG_VMAP_STACK=y
  ima: Alloc ima_max_digest_data in xattr_verify() if
    CONFIG_VMAP_STACK=y

 security/integrity/evm/evm_main.c     | 26 +++++++++++++++++++++-----
 security/integrity/ima/ima_appraise.c | 19 ++++++++++++++++---
 2 files changed, 37 insertions(+), 8 deletions(-)

-- 
2.25.1