linux-modules.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lucas De Marchi <lucas.de.marchi@gmail.com>
To: Jack Rosenthal <jrosenth@chromium.org>
Cc: linux-modules <linux-modules@vger.kernel.org>,
	Jessica Yu <jeyu@kernel.org>
Subject: Re: Module compression & loadpin
Date: Tue, 6 Aug 2019 15:53:28 -0700	[thread overview]
Message-ID: <CAKi4VA+5YBaKHoEy819MBDoCTPY9Wsu=DzXPFaibAjL91GjhzA@mail.gmail.com> (raw)
In-Reply-To: <20190802183243.GA246294@chromium.org>

+Jessica

On Sat, Aug 3, 2019 at 9:50 AM Jack Rosenthal <jrosenth@chromium.org> wrote:
>
> Has anyone looked into what it may take to support both module
> compression and loadpin (ensures modules come from trusted filesystem)?
>
> From my understanding, this is not supported as kmod currently does the
> decompression of modules, and loadpin prefers fload_module as it can
> tell where the module came from. (https://crbug.com/777204)
>
> In a gist, I am thinking supporting this scenario would require the
> module decompression to happen on the kernel side. Wondering if anyone
> has looked into this before I go making a solution...

That's my thought as well. In order to use finit_module() with
compressed modules we need to teach the kernel how to open it. It
should not be difficult since kernel already has the decompression
libraries. This also gives us access to another
compression/decompression algorithms - but would be nice to have a
correspondent implementation for modinfo.

I planned to do that some years ago, but never implemented it. Nobody
that I know of is currently working on that. It would be a very
welcome contribution.

Jessica, any comment on having this on the kernel side?

Thanks
Lucas De Marchi


>
> Thanks,
>
> Jack




--
Lucas De Marchi

  reply	other threads:[~2019-08-06 22:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190731222209.GA101140@chromium.org>
2019-08-02 18:32 ` Module compression & loadpin Jack Rosenthal
2019-08-06 22:53   ` Lucas De Marchi [this message]
2019-08-08 13:24     ` Jessica Yu

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='CAKi4VA+5YBaKHoEy819MBDoCTPY9Wsu=DzXPFaibAjL91GjhzA@mail.gmail.com' \
    --to=lucas.de.marchi@gmail.com \
    --cc=jeyu@kernel.org \
    --cc=jrosenth@chromium.org \
    --cc=linux-modules@vger.kernel.org \
    /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 NNTP newsgroup(s).