Linux-Modules Archive on lore.kernel.org
 help / color / Atom feed
* Module compression & loadpin
       [not found] <20190731222209.GA101140@chromium.org>
@ 2019-08-02 18:32 ` Jack Rosenthal
  2019-08-06 22:53   ` Lucas De Marchi
  0 siblings, 1 reply; 3+ messages in thread
From: Jack Rosenthal @ 2019-08-02 18:32 UTC (permalink / raw)
  To: linux-modules

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...

Thanks,

Jack

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Module compression & loadpin
  2019-08-02 18:32 ` Module compression & loadpin Jack Rosenthal
@ 2019-08-06 22:53   ` Lucas De Marchi
  2019-08-08 13:24     ` Jessica Yu
  0 siblings, 1 reply; 3+ messages in thread
From: Lucas De Marchi @ 2019-08-06 22:53 UTC (permalink / raw)
  To: Jack Rosenthal; +Cc: linux-modules, Jessica Yu

+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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Module compression & loadpin
  2019-08-06 22:53   ` Lucas De Marchi
@ 2019-08-08 13:24     ` Jessica Yu
  0 siblings, 0 replies; 3+ messages in thread
From: Jessica Yu @ 2019-08-08 13:24 UTC (permalink / raw)
  To: Lucas De Marchi; +Cc: Jack Rosenthal, linux-modules

+++ 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


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20190731222209.GA101140@chromium.org>
2019-08-02 18:32 ` Module compression & loadpin Jack Rosenthal
2019-08-06 22:53   ` Lucas De Marchi
2019-08-08 13:24     ` Jessica Yu

Linux-Modules Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-modules/0 linux-modules/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-modules linux-modules/ https://lore.kernel.org/linux-modules \
		linux-modules@vger.kernel.org linux-modules@archiver.kernel.org
	public-inbox-index linux-modules


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-modules


AGPL code for this site: git clone https://public-inbox.org/ public-inbox