public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Adam Zabrocki <pi3@pi3.com.pl>
To: Jessica Yu <jeyu@kernel.org>
Cc: Nicolas Morey-Chaisemartin <nmoreychaisemartin@suse.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, Solar Designer <solar@openwall.com>
Subject: Re: Linux Kernel module notification bug
Date: Tue, 12 Jan 2021 01:15:59 +0100	[thread overview]
Message-ID: <20210112001559.GA20073@pi3.com.pl> (raw)
In-Reply-To: <20210111142048.GA27038@linux-8ccs>

Hello,

On Mon, Jan 11, 2021 at 03:20:48PM +0100, Jessica Yu wrote:
> +++ Adam Zabrocki [10/01/21 18:54 +0100]:
> > Hello,
> > 
> > I believe that the following commit does introduce a gentle "functionality
> > bug":
> > 
> > "module: delay kobject uevent until after module init call":
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/kernel/module.c?id=38dc717e97153e46375ee21797aa54777e5498f3
> > 
> > The official Linux Kernel API for the kernel module activities notification has
> > been divided based on the readiness 'stage' for such module. We have the
> > following stages:
> > 
> >        MODULE_STATE_LIVE,      /* Normal state. */
> >        MODULE_STATE_COMING,    /* Full formed, running module_init. */
> >        MODULE_STATE_GOING,     /* Going away. */
> >        MODULE_STATE_UNFORMED,  /* Still setting it up. */
> > 
> > LIVE means that the kernel module is correctly running and all initialization
> > work has been already done. Otherwise, we have event 'COMING' or 'UNFORMED'.
> > 
> > In the described commit, creation of the KOBJECT has been moved after invoking
> > a notficiation of the newly formed kernel module state (LIVE). That's somehow
> > inconsistent from my understanding of the kernel modules notifiers logic.
> > Creation of the new objects (like KOBJ) should be done before notification of
> > the stage LIVE is invoked.
> 
> I'm confused. We're not creating any kobjects here. That is all done
> in mod_sysfs_setup(), which is called while the module is still
> COMING.  What that commit does is delay telling userspace about the
> module (specifically, systemd/udev) until the module is basically
> ready. Systemd was basically receiving the uevent too early, before
> the module has initialized, hence we decided to delay the uevent [1].
> 

Sorry for the confusion on my side. I was referring to the internal state of 
the KOBJ itself which is being actively modified when uevent is sent. During 
the module creation KOBJ_ADD modifies 'kobj->state_add_uevent_sent'. Until 
recent commit, kernel didn't modify KOBJ after sending LIVE notification.

> > This commit breaks some of the projects that rely on the LIVE notification to
> > monitor when the newly loaded module is ready.
> 
> Hm, could you please explain specifically what is the issue you're seeing?
> What projects is it breaking?
> 

I'm specifically referencing these projects which are tracking kernel modules
for integrity purpose (e.g. anti-rootkit tools) like Linux Kernel Runtime 
Guard.
It is possible to modify these tools to adopt and take into account 
modification of KOBJ after LIVE state notification. However, from my 
understanding of the kernel modules notifiers logic, KOBJ should be fully 
formed at this stage.

Thanks,
Adam

> Thanks,
> 
> Jessica
> 
> [1] https://github.com/systemd/systemd/issues/17586

-- 
pi3 (pi3ki31ny) - pi3 (at) itsec pl
http://pi3.com.pl


  reply	other threads:[~2021-01-12  0:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-10 17:54 Linux Kernel module notification bug Adam Zabrocki
2021-01-11 14:20 ` Jessica Yu
2021-01-12  0:15   ` Adam Zabrocki [this message]
2021-01-12 10:46     ` Jessica Yu
2021-01-12 11:00       ` Greg Kroah-Hartman
2021-01-13  0:33       ` [PATCH] module: invoke kobject uevent before sending LIVE notification Adam Zabrocki
2021-01-13  7:44         ` Greg Kroah-Hartman

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=20210112001559.GA20073@pi3.com.pl \
    --to=pi3@pi3.com.pl \
    --cc=gregkh@linuxfoundation.org \
    --cc=jeyu@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nmoreychaisemartin@suse.com \
    --cc=solar@openwall.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