Re: [dm-devel] [PATCH v2 2/2] IMA: Add test for dm-crypt measurement

2021-05-06 Thread Petr Vorel
Hi Tushar, Mimi, Lakshmi, > New functionality is being added to IMA to measure data provided by > kernel components. With this feature, IMA policy can be set to enable > measuring data provided by device-mapper targets. Currently one such > device-mapper target - dm-crypt, is being updated to use

[dm-devel] [PATCH v3 1/2] IMA: Generalize key measurement tests

2021-02-23 Thread Petr Vorel
From: Tushar Sugandhi Refactor check_keys_policy() and test1() implemented in ima_keys.sh to make it generic, and move the functionality to ima_setup.sh, to be used for measurements in other tests in the future. Suggested-by: Petr Vorel Reviewed-by: Petr Vorel Signed-off-by: Tushar Sugandhi

[dm-devel] [PATCH v3 0/2] IMA: Add test for dm-crypt measurement

2021-02-23 Thread Petr Vorel
Hi! I updated Tushar's patchset to speedup things. Changes v2->v3 * rename function s/check_ima_ascii_log_for_policy/test_policy_measurement/ * move tst_res TPASS/TFAIL into test_policy_measurement() * drop template=ima-buf (see Lakshmi's patch [1] and discussion about it, it will be removed

[dm-devel] [PATCH v3 2/2] IMA: Add test for dm-crypt measurement

2021-02-23 Thread Petr Vorel
this functionality. This new functionality needs test automation in LTP. Add a testcase which verifies that the IMA subsystem correctly measures the data coming from a device-mapper target - dm-crypt. Reviewed-by: Petr Vorel Signed-off-by: Tushar Sugandhi [ pvorel: adapt to previous commit changes

Re: [dm-devel] [PATCH v2 1/2] IMA: generalize key measurement tests

2021-02-23 Thread Petr Vorel
Hi Tushar, > Thanks for your review. > My sincere apologies for missing this email and not responding in time. > The device mapper measurement work is being revisited - to cover aspects > like more DM targets (not just dm-crypt), better memory management, > more relevant attributes from the DM

Re: [dm-devel] [PATCH v2 2/2] IMA: Add test for dm-crypt measurement

2021-01-12 Thread Petr Vorel
Hi Tushar, ... > +++ b/testcases/kernel/security/integrity/ima/tests/ima_dm_crypt.sh > @@ -0,0 +1,60 @@ > +#!/bin/sh > +# SPDX-License-Identifier: GPL-2.0-or-later > +# Copyright (c) 2020 Microsoft Corporation > +# Author: Tushar Sugandhi > +# > +# Verify that DM target dm-crypt are measured

Re: [dm-devel] [PATCH v2 1/2] IMA: generalize key measurement tests

2020-12-21 Thread Petr Vorel
Hi Tushar, I'm very sorry about the delay. I'll finish this review in January, here just some quick thoughts (minor style nits, I'll fix it before merge). Generally LGTM, thanks for your work. Reviewed-by: Petr Vorel > New functionality is being added in IMA to measure data provi

Re: [dm-devel] [PATCH 05/24] block: remove the update_bdev parameter from set_capacity_revalidate_and_notify

2020-11-13 Thread Petr Vorel
Hi Christoph, > The update_bdev argument is always set to true, so remove it. Also > rename the function to the slighly less verbose set_capacity_and_notify, > as propagating the disk size to the block device isn't really > revalidation. > Signed-off-by: Christoph Hellwig Re

Re: [dm-devel] [PATCH] IMA: Add test for dm-crypt measurement

2020-09-10 Thread Petr Vorel
Hi Tushar, > > > IMA subsystem supports measuring data from other kernel components > > > through func=CRITICAL_DATA policy 'critical_kernel_data_sources'. > > > This IMA policy can be set to measure the data coming from device-mapper > > > targets. This scenario needs test coverage. > > Thank

Re: [dm-devel] [PATCH] IMA: Add test for dm-crypt measurement

2020-09-01 Thread Petr Vorel
Hi Tushar, > IMA subsystem supports measuring data from other kernel components > through func=CRITICAL_DATA policy 'critical_kernel_data_sources'. > This IMA policy can be set to measure the data coming from device-mapper > targets. This scenario needs test coverage. Thank you for your patch.

[dm-devel] [RFC PATCH v2 1/2] kpartx: Use fixed size types in struct solaris_x86_slice

2019-10-12 Thread Petr Vorel
quot;) Cc: Christoph Hellwig Cc: Baruch Even Signed-off-by: Petr Vorel --- changes v1->v2: * use user space types __le{16,32} => uint{16,32}_t kpartx/solaris.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/kpartx/solaris.c b/kpartx/solaris.c index e7

[dm-devel] [RFC PATCH v2 2/2] kpartx: Use fixed size types in struct solaris_x86_vtoc

2019-10-12 Thread Petr Vorel
: keep timestamp[SOLARIS_X86_NUMSLICE] as time_t (kernel uses unsigned int). Cc: Christoph Hellwig Cc: Baruch Even Signed-off-by: Petr Vorel --- changes v1->v2: new commit. kpartx/solaris.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/kpartx/solaris.

Re: [dm-devel] [PATCH 1/1] kpartx: Use __kernel_daddr_t for solaris_x86_slice.s_start

2019-10-12 Thread Petr Vorel
Hi Baruch, > Hi, > The patch looks good to me, as for gpart, I needed it so I've taken the > bits and pieces that floated around and merged them all into one place from > all distributions that I could find. As for users, in Debian the number > of users is around 250 so it's a very low usage

Re: [dm-devel] [PATCH 1/1] kpartx: Use __kernel_daddr_t for solaris_x86_slice.s_start

2019-10-08 Thread Petr Vorel
Hi Christoph, > On Wed, Oct 02, 2019 at 08:05:09AM +0200, Petr Vorel wrote: > > I tried to search in [1], with not much success, I don't know the original > > name > > of the struct and struct members are quite similar. Do you have a tip, > > where it > > cou

[dm-devel] [RFC PATCH 1/1] kpartx: Use solaris_x86_slice definition from kernel

2019-10-08 Thread Petr Vorel
/ int / daddr_t, which is IMHO wrong and tried to address only s_start struct member. Fixes: 129e6fe6 ("kpartx: Use __kernel_daddr_t for solaris_x86_slice.s_start") Cc: Christoph Hellwig Cc: Baruch Even Signed-off-by: Petr Vorel --- kpartx/solaris.c | 8 1 file changed, 4

Re: [dm-devel] [PATCH 1/1] kpartx: Use __kernel_daddr_t for solaris_x86_slice.s_start

2019-10-02 Thread Petr Vorel
Hi Christoph, > On Tue, Jul 09, 2019 at 10:02:05AM +0200, Petr Vorel wrote: > > > What this really should use is fixed size types. > > If it's not specific to __kernel_daddr_t nor daddr_t ("The type of a disk > > address") and long is sufficient for all platf

Re: [dm-devel] [multipath-tools] merges

2019-10-01 Thread Petr Vorel
Hi Christophe, > Petr, do you intent to submit a v2 of the s/daddr_t/__kernel_daddr_t/ patch > posted jul 08, following Christoph H's comment ... or is the posted version > fit for inclusion ? I see you already merged it as 129e6fe6 ("kpartx: Use __kernel_daddr_t for solaris_x86_slice.s_start").

Re: [dm-devel] [PATCH 1/1] kpartx: Use __kernel_daddr_t for solaris_x86_slice.s_start

2019-07-09 Thread Petr Vorel
Hi Christoph, > > -//typedef int daddr_t; /* or long - check */ > > - > > struct solaris_x86_slice { > > unsigned short s_tag; /* ID tag of partition */ > > unsigned short s_flag; /* permission flags */ > > - longs_start;/* start

[dm-devel] [PATCH 1/1] kpartx: Use __kernel_daddr_t for solaris_x86_slice.s_start

2019-07-08 Thread Petr Vorel
It was meant to be used daddr_t (which is mostly int, only sparc and mips have it defined as int), but instead used long. But musl libc does not define daddr_t as it's deprecated, therefore use __kernel_daddr_t from . Signed-off-by: Petr Vorel --- kpartx/solaris.c | 6 ++ 1 file changed, 2