[RFC][PATCH v2 06/12] diglim: Interfaces - digest_list_add, digest_list_del

Roberto Sassu roberto.sassu at huawei.com
Mon Aug 2 08:14:20 UTC 2021


> From: Roberto Sassu [mailto:roberto.sassu at huawei.com]
> Sent: Friday, July 30, 2021 4:25 PM
> > From: Mimi Zohar [mailto:zohar at linux.ibm.com]
> > Sent: Friday, July 30, 2021 4:03 PM
> > Hi Roberto,
> >
> > On Fri, 2021-07-30 at 13:16 +0000, Roberto Sassu wrote:
> > > > From: Mimi Zohar [mailto:zohar at linux.ibm.com]
> > > > Sent: Friday, July 30, 2021 2:40 PM
> >
> > > > "critical data", in this context, should probably be used for verifying
> > > > the in memory file digests and other state information haven't been
> > > > compromised.
> > >
> > > Actually, this is what we are doing currently. To keep the
> > > implementation simple, once the file or the buffer are uploaded
> > > to the kernel, they will not be modified, just accessed through
> > > the indexes.
> >
> > My main concern about digest lists is their integrity, from loading the
> > digest lists to their being stored in memory.  A while back, there was
> > some work on defining a write once memory allocator.  I don't recall
> > whatever happened to it.  This would be a perfect usecase for that
> > memory allocator.
> 
> Adding Igor in CC.
> 
> Regarding loading, everything uploaded to the kernel is carefully
> evaluated. This should not be a concern. Regarding making them
> read-only, probably if you can subvert digest lists you can also
> remove the read-only protection (unless you use an hypervisor).

I briefly talked with Igor. He also agreed with that, and added that
it could make it more difficult for an attacker to also disable the
protection. However, he is not planning to submit an update soon,
so I wouldn't consider this an option for now.

Thanks

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli

> Thanks
> 
> Roberto
> 
> HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
> Managing Director: Li Peng, Li Jian, Shi Yanli
> 
> > thanks,
> >
> > Mimi



More information about the Linux-security-module-archive mailing list