g should only contain an entry when the table changed.
Signed-off-by: Thore Sommer
---
- v1: rewrite check to not use an extra variable
drivers/md/dm-verity-target.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-veri
The dm_target_update event can be triggered by targets to remeasure their
state to reflect that change also in IMA.
This is event is currently only supported by verity.
Signed-off-by: Thore Sommer
---
.../admin-guide/device-mapper/dm-ima.rst | 33 +++
1 file changed, 33
gle commit messages
[1] https://keylime.dev/
[2]
https://lore.kernel.org/linux-integrity/20220106203436.281629-1-pub...@thson.de/T/
Thore Sommer (3):
dm ima: allow targets to remeasure their table entry
dm verity: add support for IMA target update event
dm ima: add documentation target up
s measured.
The hash of the active table is not updated because it would require to
rehash the whole table with all the other targets entries.
Signed-off-by: Thore Sommer
---
- v1:
- do not initialize ima_buf with NULL
- use return value of scnprintf for target_metadata_buf_len
Hi Lakshmi,
On 06.05.22 22:25, Lakshmi Ramasubramanian wrote:
Hi Thore,
On 1/6/2022 12:34 PM, Thore Sommer wrote:
A new DM event dm_target_update is introduced for targets to remeasure
their table entry. This is intended for targets that indicate security
relevant events by updating one of
Hi Lakshmi,
On 06.05.22 22:35, Lakshmi Ramasubramanian wrote:
Hi Thore,
On 1/6/2022 12:34 PM, Thore Sommer wrote:
On first corruption the verity targets triggers a dm_target_update event.
This allows other systems to check using IMA if the state of the
device is
still trustworthy via remote
Hi Lakshmi,
thank you for taking a closer look at this patch set.
On 06.05.22 22:16, Lakshmi Ramasubramanian wrote:
Hi Thore,
On 1/6/2022 12:34 PM, Thore Sommer wrote:
The current DM IMA events do not cover the case where a device changes
their attributes to indicate a state change.
It
wrong because it contains the version string twice.
This caused entries like this:
dm_version=4.45.0;name=test,uuid=test;table_clear=no_data; \
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \
current_device_capacity=204808;
Signed-off-by: Thore Sommer
---
drivers/md
ts over
multiple IMA events.
Signed-off-by: Thore Sommer
---
v3: fixed missing spaces
v2:
- include also device name and uuid in grammar for no_data
- fixed spelling mistakes
.../admin-guide/device-mapper/dm-ima.rst | 32 +++
1 file changed, 26 insertions(+), 6 deleti
ts over
multiple IMA events.
Signed-off-by: Thore Sommer
---
v2:
- include also device name and uuid in grammar for no_data
- fixed spelling mistakes
.../admin-guide/device-mapper/dm-ima.rst | 32 +++
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/Documentatio
On first corruption the verity targets triggers a dm_target_update event.
This allows other systems to check using IMA if the state of the device is
still trustworthy via remote attestation.
Signed-off-by: Thore Sommer
---
drivers/md/dm-verity-target.c | 6 ++
1 file changed, 6 insertions
The dm_target_update event can be triggered by targets to remeasure their
state to reflect that change also in IMA.
This is event is currently only supported by verity.
Signed-off-by: Thore Sommer
---
.../admin-guide/device-mapper/dm-ima.rst | 33 +++
1 file changed, 33
only verity supports this event to ensure that device corruption
can be detected using IMA which is useful for remote attestation.
The current implementation does not update the active table hash because
it would require to rehash the entire table on every target change.
Thore Sommer (3):
dm ima
measured.
This does not update the hash of the active table because it would require
to rehash the whole table with all the other targets entries.
Signed-off-by: Thore Sommer
---
drivers/md/dm-ima.c | 76 +
drivers/md/dm-ima.h | 2 ++
2 files changed, 78
ts over
multiple IMA events.
Signed-off-by: Thore Sommer
---
.../admin-guide/device-mapper/dm-ima.rst | 26 ++-
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/Documentation/admin-guide/device-mapper/dm-ima.rst
b/Documentation/admin-guide/device-mapper/dm-ima.rs
Hi Alasdair,
thank you for the explanation and pointing me into the right direction.
I was wondering how we can differentiate the different devices in the remote
attestation service and now I think that I understand the format of the uuids,
so that we can implement a parser/validator for that.
Hi Tushar,
thank you for answering my questions and looking at my suggestions.
> I can update the verity_status() to measure if v->signature_key_desc is
> set.
>
> Something like:
> DMEMIT("signature_key_desc_present=%c,", v->signature_key_desc ? 'y' :
> 'n');
If my understanding that this ent
Hi Alasdair,
thank you for answering my questions. The answers helped a lot.
> Having other triggering mechanisms - such as hooking into internal
> events when something unexpected happens - could be considered for
> follow-on patches.
I've written [1] a proof of concept implementation that prov
Hi Tushar,
> Most likely this is because you haven't set CONFIG_IMA_DISABLE_HTABLE=y.
Yes, that was the case.
With CONFIG_IMA_DISABLE_HTABLE=y the behavior is as expected. Now a new
measurement is created if I create the same device twice.
Regards,
Thore
--
dm-devel mailing list
dm-devel@redha
Hello Tushar,
I've now tested your patches more in depth. I've used the latest changes from
the dm-5.15 branch. Here are some things that I noticed during testing with
dm-verity. I'm relative new to IMA and device mapper, so there are also some
more general questions.
No new IMA measurement is ge
ustom solution.
We tested the initial RFC patch set and will continue testing with this one to
see if it fully works in our environment and with our use case.
Thore Sommer
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
21 matches
Mail list logo
