From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "Mimi Zohar" <zohar@linux.ibm.com>,
"Luis Chamberlain" <mcgrof@kernel.org>
Cc: <linux-modules@vger.kernel.org>,
<linux-integrity@vger.kernel.org>,
"Roberto Sassu" <roberto.sassu@huawei.com>,
<linux-kernel@vger.kernel.org>,
"Ken Goldman" <kgold@linux.ibm.com>
Subject: Re: [PATCH] ima: define an init_module critical data record
Date: Thu, 28 Mar 2024 05:08:56 +0200 [thread overview]
Message-ID: <D051WQKNXETS.1O1TI7O2DPT1Z@kernel.org> (raw)
In-Reply-To: <80b2e479bc0c520423885a16dd46e0201a1c9418.camel@linux.ibm.com>
On Wed Mar 27, 2024 at 11:37 PM EET, Mimi Zohar wrote:
> On Wed, 2024-03-27 at 18:54 +0200, Jarkko Sakkinen wrote:
> > On Wed Mar 27, 2024 at 5:00 PM EET, Mimi Zohar wrote:
> > > The init_module syscall loads an ELF image into kernel space without
> > > measuring the buffer containing the ELF image. To close this kernel
> > > module integrity gap, define a new critical-data record which includes
> > > the hash of the ELF image.
> > >
> > > Instead of including the buffer data in the IMA measurement list,
> > > include the hash of the buffer data to avoid large IMA measurement
> > > list records. The buffer data hash would be the same value as the
> > > finit_module syscall file hash.
> > >
> > > To enable measuring the init_module buffer and other critical data from
> > > boot, define "ima_policy=critical_data" on the boot command line. Since
> > > builtin policies are not persistent, a custom IMA policy must include
> > > the rule as well: measure func=CRITICAL_DATA label=modules
> > >
> > > To verify the template data hash value, first convert the buffer data
> > > hash to binary:
> > > grep "init_module" \
> > > /sys/kernel/security/integrity/ima/ascii_runtime_measurements | \
> > > tail -1 | cut -d' ' -f 6 | xxd -r -p | sha256sum
> > >
> > > Reported-by: Ken Goldman <kgold@linux.ibm.com>
> > > Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
> > > ---
> > > security/integrity/ima/ima_main.c | 7 +++++++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/security/integrity/ima/ima_main.c
> > > b/security/integrity/ima/ima_main.c
> > > index c84e8c55333d..4b4348d681a6 100644
> > > --- a/security/integrity/ima/ima_main.c
> > > +++ b/security/integrity/ima/ima_main.c
> > > @@ -902,6 +902,13 @@ static int ima_post_load_data(char *buf, loff_t size,
> > > return 0;
> > > }
> > >
> > > + /*
> > > + * Measure the init_module syscall buffer containing the ELF image.
> > > + */
> > > + if (load_id == LOADING_MODULE)
> > > + ima_measure_critical_data("modules", "init_module",
> > > + buf, size, true, NULL, 0);
> >
> > No reason not to ack but could be just as well (passing checkpatch):
>
> Please review the tag usage as defined in
> https://docs.kernel.org/process/submitting-patches.html.
>
> >
> > if (load_id == LOADING_MODULE)
> > ima_measure_critical_data("modules", "init_module", buf, size,
> > true, NULL, 0);
> >
> > < 100 characters
>
> From what I understand, it's still preferable to stay under the 80 character
> limit, but checkpatch.pl will not complain. From
> https://www.kernel.org/doc/Documentation/process/maintainer-tip.rst:
>
> "The 80 character rule is not a strict rule, so please use common sense when
> breaking lines. Especially format strings should never be broken up."
I agree with that is your decision to make (as maintainer of
IMA)!
BTW, I guess process/coding-style.rst would be better ref
here because maintainer-tip.rst is meant only for arch/x86
tree (aka tip.git).
That said, both maintainer-tip.rst and coding-style.rst recommend
the same 80 character length. I have no idea whether 80 or 100
character should be considered as "recommended".
The formatted string example is somewhat weird too because you
should not break that even if it was 150 characters so it does
not have any relation to 100 character limit...
R, Jarkko
prev parent reply other threads:[~2024-03-28 3:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-27 15:00 [PATCH] ima: define an init_module critical data record Mimi Zohar
2024-03-27 16:54 ` Jarkko Sakkinen
2024-03-27 21:37 ` Mimi Zohar
2024-03-28 3:08 ` Jarkko Sakkinen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D051WQKNXETS.1O1TI7O2DPT1Z@kernel.org \
--to=jarkko@kernel.org \
--cc=kgold@linux.ibm.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=roberto.sassu@huawei.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).