On Wed, 2021-07-21 at 11:42 -0400, Mike Snitzer wrote:
> On Tue, Jul 20 2021 at 10:12P -0400,
> Mimi Zohar <zohar@xxxxxxxxxxxxx> 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.
This goes back to my question as to if or how the template data in
these DM critical data records are to be validated by the attestation
server. Asumming the hash/hash_len is being stored in the IMA
measurement list, the less the attestation should need to know about
the specific kernel version the better.
thanks,
Mimi
