[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1305894545.3247.43.camel@localhost.localdomain>
Date: Fri, 20 May 2011 08:29:05 -0400
From: Mimi Zohar <zohar@...ux.vnet.ibm.com>
To: "Serge E. Hallyn" <serge@...lyn.com>
Cc: linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
James Morris <jmorris@...ei.org>,
David Safford <safford@...son.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Greg KH <greg@...ah.com>,
Dmitry Kasatkin <dmitry.kasatkin@...ia.com>,
Mimi Zohar <zohar@...ibm.com>
Subject: Re: [PATCH v5 03/21] evm: re-release
On Thu, 2011-05-19 at 16:37 -0500, Serge E. Hallyn wrote:
> Quoting Mimi Zohar (zohar@...ux.vnet.ibm.com):
> ...
> > +extern int evm_hmac_size;
> ...
> > +int evm_hmac_size = SHA1_DIGEST_SIZE;
>
> I think I object to having both MAX_DIGEST_SIZE and evm_hmac_size, both
> of which are set to SHA1_DIGEST_SIZE throughout this patchset. Especially
> because of the comment I was about to make on patch 4/21, where you
> then prepend the hmac with a 'type' byte, and start passing around
> MAX_DIGEST_SIZE+1 and evm_hmac_size+1.
>
> Even if you're going to be using those differently in a later patchset,
> let's focus on this set for now and keep things simpler. One constant
> for the hmac size, and then please define a new one (in patch 4) for
> the annotated digest size. I can't think think of a good name. Which
> suggests that perhaps you should define a nicely typed struct to contain
> the header+hmac...
>
> I see no other problems, so presuming that these are nicely addressed
> I expect to happily ack.
>
> thanks,
> -serge
Ok, MAX_DIGEST_SIZE was defined in the first patch of this patchset,
which moves the iint from IMA to integrity, but it seems to be
unnecessary for any of the additional EVM or IMA extensions, including
support for additional IMA hash sizes. I'll remove MAX_DIGEST_SIZE.
The reason for introducing the extra byte at this point in the patch
set, as opposed to waiting to do so in the digital signature patches, is
to permit existing labeled systems to continue to run properly (and be
bisect safe). Defining a structure is a good idea.
thanks,
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists