linux-kernel - Re: Modularizing IOMMUs (devel/iommu-0.4)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 20 Oct 2010 13:23:53 -0700
From:	"H. Peter Anvin" <hpa@...ux.intel.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC:	fujita.tomonori@....ntt.co.jp, JBeulich@...ell.com,
	jeremy@...p.org, linux-kernel@...r.kernel.org
Subject: Re: Modularizing IOMMUs (devel/iommu-0.4)

On 10/20/2010 01:20 PM, Konrad Rzeszutek Wilk wrote:
> Hey Peter, Tomo-san, Jan and Jeremy, and LKML:
> 
> I was wondering if I could run this idea by you guys. One of the things that
> Peter proposed was in some ways to "modularize" the IOMMUs (and potentially
> later on use that framework to "modularize" other built-in components). For details:
> http://lkml.org/lkml/2010/8/2/282 and the follow-on threads.
> 
> If you want to look at code right away, I've some beginnings at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb-2.6.git devel/iommu-0.4
> (look at patches past swiotlb-xen: Remove the unnecessary EXPORT_SYMBOL_GPL macros)
> 
> The 10,000 ft view is that during bootup, we want to jettison those IOMMUs
> that are built-in, but actually aren't used b/c the machine does not have it.
> Once it is identified which one we don't want, we mark those sections as available
> for the kernel memory subsystem and we can shed some kilobytes.
> 
> So the first step is to identify the functions for the IOMMUs. And also
> group them tightly together. The path I pursued was to stick all of the
> executable sections in clearly identifiable sections that can be
> easily identified.
> 

I think a much better way to do this is something I discussed with Linus
at least 12 years ago, which is allow modules to be built into the
kernel, but still be unloadable using the actual module mechanism.  This
means they are part of the full kernel image and therefore immediately
available, but appear to the module system as an already-installed
module.  Then we can unload modules to free up space.

This would be a handy thing to have in general, and would simplify this
kind of stuff tremendously.

	-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/