From: Tushar Sugandhi <firstname.lastname@example.org>
To: Mike Snitzer <email@example.com>
Cc: firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
Subject: Re: [dm-devel] [PATCH 0/7] device mapper target measurements using IMA
Date: Fri, 23 Jul 2021 23:57:07 -0700 [thread overview]
Message-ID: <email@example.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 4354 bytes --]
On 7/20/21 2:27 PM, Mike Snitzer wrote:
> On Mon, Jul 12 2021 at 8:48P -0400,
> Tushar Sugandhi <firstname.lastname@example.org> wrote:
>> For a given system, various external services/infrastructure tools
>> (including the attestation service) interact with it - both during the
>> setup and during rest of the system run-time. They share sensitive data
>> and/or execute critical workload on that system. The external services
>> may want to verify the current run-time state of the relevant kernel
>> subsystems before fully trusting the system with business-critical
>> Device mapper is one such kernel subsystem that plays a critical role on
>> a given system by providing various important functionalities to the
>> block devices with various target types like crypt, verity, integrity
>> etc. Each of these target types’ functionalities can be configured with
>> various attributes. The attributes chosen to configure these target types
>> can significantly impact the security profile of the block device,
>> and in-turn, of the system itself. For instance, the type of encryption
>> algorithm and the key size determines the strength of encryption for a
>> given block device.
>> Therefore, verifying the current state of various block devices as well
>> as their various target attributes is crucial for external services
>> before fully trusting the system with business-critical data/workload.
>> IMA provides the necessary functionality for device mapper to measure the
>> state and configuration of various block devices -
>> - BY device mapper itself, from within the kernel,
>> - in a tamper resistant way,
>> - and re-measured - triggered on state/configuration change.
>> This patch series uses this IMA functionality, by calling the function
>> ima_measure_critical_data(), when a block device state is changed (e.g.
>> on device create, resume, rename, remove etc.) It measures the device
>> state and configuration and stores it in IMA logs, so that it can be
>> used by external services for managing the system.
> I needed to EXPORT_SYMBOL_GPL(ima_measure_critical_data); otherwise I
> couldn't compile.. not sure but I can only imagine you compile DM
> (and all targets) to be builtin?
I believe the EXPORT_SYMBOL_GPL(ima_measure_critical_data) is now needed
because of the move “#ifdef CONFIG_IMA from dm-ima.c to dm-ima.h”, and
the associated change in the Makefile
dm-mod-objs += dm-ima.o
Earlier I needed to export symbol only if I was calling
ima_measure_critical_data() directly from various dm-*.c files.
With my earlier implementation, it wasn’t needed when it was called from
the wrapper dm_ima_measure_data() in dm-ima.c.
> In addition to fixing that (in first table load patch) I changed
> various things along the way while I reviewed each patch.
Thank you so much for making the necessary changes Mike. Really
> Things that I recall are:
> - moved #ifdef CONFIG_IMA from dm-ima.c to dm-ima.h
> - fixed various typos and whitespace
> - consistently prepend "," in STATUSTYPE_IMA's DMEMIT()s as opposed to
> having a mix or pre and postfix throughout targets
> - fixed what seemed like malformed STATUSTYPE_IMA handling for
> dm-multipath -- it was DMEMIT(";") for each dm-mpath's pathgroup
> - added some fields to dm-mpath, renamed some IMA names in name=value
> pairs to be more clear.
I went through the changes you made. They look fine. In addition to the
above changes, you also fixed a warning in dm-raid.c. (initializing the
Thanks again. :)
> I've staged the result in linux-next via linux-dm.git's dm-5.15
> branch, see:
> I've compiled tested both with and without CONFIG_IMA set. But
> haven't actually tested the code.
No worries. I will test the changesthoroughly again.
> Please send any incremental fixes relative to the dm-5.15 branch and
> I'll get them folded in where appropriate.
Ok. I will send incremental patches against dm-5.15 as you've suggested.
Thanks again for the review and all the help so far. Really appreciate
[-- Attachment #1.2: Type: text/html, Size: 8615 bytes --]
[-- Attachment #2: Type: text/plain, Size: 97 bytes --]
dm-devel mailing list
prev parent reply other threads:[~2021-07-24 6:57 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-13 0:48 [dm-devel] [PATCH 0/7] device mapper target measurements using IMA Tushar Sugandhi
2021-07-13 0:48 ` [dm-devel] [PATCH 1/7] dm: measure data on table load Tushar Sugandhi
2021-07-21 2:12 ` Mimi Zohar
2021-07-21 15:42 ` Mike Snitzer
2021-07-21 16:07 ` Mimi Zohar
2021-07-21 21:17 ` Mimi Zohar
2021-07-29 19:58 ` Tushar Sugandhi
2021-07-13 0:48 ` [dm-devel] [PATCH 2/7] dm: measure data on device resume Tushar Sugandhi
2021-07-13 0:49 ` [dm-devel] [PATCH 3/7] dm: measure data on device remove Tushar Sugandhi
2021-07-13 0:49 ` [dm-devel] [PATCH 4/7] dm: measure data on table clear Tushar Sugandhi
2021-07-13 0:49 ` [dm-devel] [PATCH 5/7] dm: measure data on device rename Tushar Sugandhi
2021-07-13 0:49 ` [dm-devel] [PATCH 6/7] dm: update target specific status functions to measure data Tushar Sugandhi
2021-07-13 1:06 ` Alasdair G Kergon
2021-07-14 20:23 ` Tushar Sugandhi
2021-07-13 0:49 ` [dm-devel] [PATCH 7/7] dm: add documentation for IMA measurement support Tushar Sugandhi
2021-07-21 2:33 ` Mimi Zohar
2021-07-24 7:25 ` Tushar Sugandhi
2021-07-26 16:33 ` Mimi Zohar
2021-07-26 18:28 ` Tushar Sugandhi
2021-07-14 11:32 ` [dm-devel] [PATCH 0/7] device mapper target measurements using IMA Thore Sommer
2021-07-14 20:20 ` Tushar Sugandhi
2021-07-27 10:18 ` Thore Sommer
2021-07-27 20:33 ` Alasdair G Kergon
2021-07-28 3:10 ` Tushar Sugandhi
2021-07-28 17:14 ` Thore Sommer
2021-07-29 17:32 ` Tushar Sugandhi
2021-07-28 17:34 ` Thore Sommer
2021-07-28 21:33 ` Alasdair G Kergon
2021-08-02 10:45 ` Thore Sommer
2021-07-29 19:24 ` Tushar Sugandhi
2021-08-02 10:38 ` Thore Sommer
2021-07-20 21:27 ` Mike Snitzer
2021-07-24 6:57 ` Tushar Sugandhi [this message]
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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;
as well as URLs for NNTP newsgroup(s).