On Mon, 2014-06-30 at 17:58 +0300, Dmitry Kasatkin wrote:
> On 26/06/14 14:54, Mimi Zohar wrote:
> > On Thu, 2014-06-19 at 18:20 +0300, Dmitry Kasatkin wrote:
> >> @@ -156,7 +316,7 @@ out:
> >> return rc;
> >> }
> >>
> >> -int ima_calc_file_hash(struct file *file, struct ima_digest_data *hash)
> >> +static int ima_calc_file_shash(struct file *file, struct ima_digest_data
> >> *hash)
> >> {
> >> struct crypto_shash *tfm;
> >> int rc;
> >> @@ -172,6 +332,20 @@ int ima_calc_file_hash(struct file *file, struct
> >> ima_digest_data *hash)
> >> return rc;
> >> }
> >>
> >> +int ima_calc_file_hash(struct file *file, struct ima_digest_data *hash)
> >> +{
> >> + loff_t i_size = i_size_read(file_inode(file));
> >> +
> >> + /* shash is more efficient small data
> >> + * ahash performance depends on data size and particular HW
> >> + * ima_ahash_size allows to specify the best value for the system
> >> + */
> >> + if (ima_ahash_size && i_size >= ima_ahash_size)
> >> + return ima_calc_file_ahash(file, hash);
> >> + else
> >> + return ima_calc_file_shash(file, hash);
> >> +}
> > If calculating the file hash using ahash fails, should it fall back to
> > using shash?
>
> If ahash fails, then it could be a HW error, which should not happen.
> IF HW fails device is broken.
I would assume it depends on the HW, if the entire device/system is
broken.
> Do you really want to fallback to shash?
Yes, in this case, there is no downside to letting it to continue
working, just slower, using the software crypto implementation. In any
case, it shouldn't be hard coded.
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
