From: Jessica Yu <jeyu@kernel.org>
To: Lucas De Marchi <lucas.de.marchi@gmail.com>
Cc: Jack Rosenthal <jrosenth@chromium.org>,
linux-modules <linux-modules@vger.kernel.org>
Subject: Re: Module compression & loadpin
Date: Thu, 8 Aug 2019 15:24:57 +0200 [thread overview]
Message-ID: <20190808132457.GB29211@linux-8ccs> (raw)
In-Reply-To: <CAKi4VA+5YBaKHoEy819MBDoCTPY9Wsu=DzXPFaibAjL91GjhzA@mail.gmail.com>
+++ Lucas De Marchi [06/08/19 15:53 -0700]:
>+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.
Indeed, I don't know of anyone currently working on that. I do not
think it should be that difficult, since as Lucas already mentioned we
already have multiple decompression libraries in the kernel to extract
the compressed kernel image on boot (see: lib/decompress.c and
friends), so at first glance, I don't think it would be too hard to
extend this functionality to the module loader. I'd welcome a patchset :)
Thanks,
Jessica
prev parent reply other threads:[~2019-08-08 13:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-31 22:22 Module compression & loadpin Jack Rosenthal
2019-08-02 18:32 ` Jack Rosenthal
2019-08-06 22:53 ` Lucas De Marchi
2019-08-08 13:24 ` Jessica Yu [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=20190808132457.GB29211@linux-8ccs \
--to=jeyu@kernel.org \
--cc=jrosenth@chromium.org \
--cc=linux-modules@vger.kernel.org \
--cc=lucas.de.marchi@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.