linux-kernel - Re: [RFC][PATCH v2 06/12] diglim: Interfaces

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2c731f07bd08f01f2a3e032814bc65ae9a8494ad.camel@linux.ibm.com>
Date:   Fri, 30 Jul 2021 10:03:13 -0400
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Roberto Sassu <roberto.sassu@...wei.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "mchehab+huawei@...nel.org" <mchehab+huawei@...nel.org>
Cc:     "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH v2 06/12] diglim: Interfaces - digest_list_add,
 digest_list_del

Hi Roberto,

On Fri, 2021-07-30 at 13:16 +0000, Roberto Sassu wrote:
> > From: Mimi Zohar [mailto:zohar@...ux.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.

thanks,

Mimi