On Tue, Jul 20 2021 at 10:12P -0400, Mimi Zohar <zo...@linux.ibm.com> wrote:
> Hi Tushar, Mike, > > On Mon, 2021-07-12 at 17:48 -0700, Tushar Sugandhi wrote: > > +struct dm_ima_device_table_metadata { > > + /* > > + * Contains data specific to the device which is common across > > + * all the targets in the table.e.g. name, uuid, major, minor etc. > > + * The values are stored in comma separated list of > > key1=val1,key2=val2; pairs > > + * delimited by a semicolon at the end of the list. > > + */ > > + char *device_metadata; > > + unsigned int device_metadata_len; > > + unsigned int num_targets; > > + > > + /* > > + * Contains the sha256 hashs of the IMA measurements of the > > + * target attributes key-value pairs from the active/inactive > > tables. > > + */ > > From past experience hard coding the hash algorithm is really not a > good idea. > > Mimi > > > + char *hash; > > + unsigned int hash_len; > > + > > +}; Hi Mimi, The dm-ima.c code is using SHASH_DESC_ON_STACK and then storing the more opaque result via 'hash' and 'hash_len'. So if/when the dm-ima.c hash algorithm were to change this detail won't change the dm_ima_device_table_metadata structure at all right? But even if changes were needed this is purely an implementation detail correct? Why might users care which algorithm is used by dm-ima to generate the hashes? Assuming there is a valid reason for users to care about this, we can improve this aspect as follow-on work.. so I don't consider this a blocker for this patchset at this point. Please clarify if you feel it should be a blocker. Thanks, Mike -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel