The original IMA buffer data measurement sizes were small (e.g. boot
command line), but the new buffer data measurement use cases have data
sizes that are a lot larger. Just as IMA measures the file data hash,
not the file data, IMA should similarly support the option for measuring
buffer data
From: Lakshmi Ramasubramanian
SELinux stores the active policy in memory, so the changes to this data
at runtime would have an impact on the security guarantees provided
by SELinux. Measuring in-memory SELinux policy through IMA subsystem
provides a secure way for the attestation service to
From: Lakshmi Ramasubramanian
Define a new critical data builtin policy to allow measuring
early kernel integrity critical data before a custom IMA policy
is loaded.
Update the documentation on kernel parameters to document
the new critical data builtin policy.
Signed-off-by: Lakshmi
A new IMA policy rule is needed for the IMA hook
ima_measure_critical_data() and the corresponding func CRITICAL_DATA for
measuring the input buffer. The policy rule should ensure the buffer
would get measured only when the policy rule allows the action. The
policy rule should also support the
IMA functions such as ima_match_keyring(), process_buffer_measurement(),
ima_match_policy() etc. handle data specific to keyrings. Currently,
these constructs are not generic to handle any func specific data.
This makes it harder to extend them without code duplication.
Refactor the keyring
IMA provides capabilities to measure file and buffer data. However,
various data structures, policies, and states stored in kernel memory
also impact the integrity of the system. Several kernel subsystems
contain such integrity critical data. These kernel subsystems help
protect the integrity
The IMA hook ima_measure_critical_data() does not support a way to
specify the source of the critical data provider. Thus, the data
measurement cannot be constrained based on the data source label
in the IMA policy.
Extend the IMA hook ima_measure_critical_data() to support passing
the data
Integrity critical data may belong to a single subsystem or it may
arise from cross subsystem interaction. Currently there is no mechanism
to group or limit the data based on certain label. Limiting and
grouping critical data based on a label would make it flexible and
configurable to measure.
IMA measures files and buffer data such as keys, command-line arguments
passed to the kernel on kexec system call, etc. While these measurements
are necessary for monitoring and validating the integrity of the system,
they are not sufficient. Various data structures, policies, and states
stored
Thanks Martin, I will try to reproduce this issue with the latest version when
the enviroments ready, if reproduce it again I will let you know, thanks again~
On 2021/1/7 19:27, Martin Wilck wrote:
On Thu, 2021-01-07 at 10:23 +0800, Chongyun Wu wrote:
Hello Martin,
Thanks for view this patch.
On Wed, Dec 23 2020 at 6:26am -0500,
Jeffle Xu wrote:
> This is actuaaly the core when supporting iopoll for bio-based device.
>
> A list is maintained in the top bio (the original bio submitted to dm
> device), which is used to maintain all valid cookies of split bios. The
> IO polling
On Wed, Dec 23 2020 at 6:26am -0500,
Jeffle Xu wrote:
> Currently the returned cookie of bio-based device is not used at all.
>
> In the following patches, bio-based device will actually return a
> pointer to a specific object as the returned cookie.
In the following patch, ...
>
On Wed, Dec 23 2020 at 6:26am -0500,
Jeffle Xu wrote:
> To support iopoll for bio-based device, the returned cookie is actually
> a pointer to an implementation specific object, e.g. an object
> maintaining all split bios.
>
> In such case, blk_qc_t should be large enough to contain one
On Wed, Dec 23 2020 at 6:26am -0500,
Jeffle Xu wrote:
> ->poll_fn is introduced in commit ea435e1b9392 ("block: add a poll_fn
> callback to struct request_queue") for supporting non-mq queues such as
> nvme multipath, but removed in commit 529262d56dbe ("block: remove
> ->poll_fn").
>
> To add
On Wed, Dec 23 2020 at 6:26am -0500,
Jeffle Xu wrote:
> Sometimes we need to get the corresponding gendisk from request_queue.
>
> One such use case is that, the block device driver had ever stored the
> same private data both in queue->queuedata and gendisk->private_data,
> while nowadays
On Wed, Dec 23 2020 at 6:26am -0500,
Jeffle Xu wrote:
> So that kiocb.ki_cookie can be defined as blk_qc_t, which will enforce
> the encapsulation.
>
> Signed-off-by: Jeffle Xu
> ---
> include/linux/blk_types.h | 2 +-
> include/linux/fs.h| 2 +-
> include/linux/types.h | 3 +++
>
On Thu, 2021-01-07 at 10:23 +0800, Chongyun Wu wrote:
> Hello Martin,
> Thanks for view this patch.
>
> On 2021/1/7 5:10, Martin Wilck wrote:
> > Hello Chongyun,
> >
> > On Mon, 2020-12-28 at 11:34 +0800, Chongyun Wu wrote:
> > > From 37c74873acfc1587e79a6504ca3d42b8fa00d49e Mon Sep 17
> > >
Hi Mike,
Would you please give some suggestions on this series?
Thanks,
Jeffle
On 12/23/20 7:26 PM, Jeffle Xu wrote:
> This patch set adds support of iopoll for dm devices.
>
> Several months ago, I also sent a patch set adding support of iopoll
> for dm devices [1]. The old patch set
18 matches
Mail list logo
