Re: [unused symbol] need to use init_mm

[Eric Lacombe]

On Thu, Apr 30, 2009, Ingo Molnar wrote :
> * Mel Gorman <mel@xxxxxxxxx> wrote:
> > On Thu, Apr 30, 2009 at 12:32:04PM +0200, Eric Lacombe wrote:
> > > Hi,
> > >
> > > Within a module I work on, I need to access to init_mm, but as it is
> > > marked UNUSED, I wonder if there is another way (an API) to access to
> > > it. Otherwise, what can I do to have this mark removed from init_mm in
> > > the mainline? as my module is really not yet ready for inclusion.
> > >
> > > Thanks in advance for your response,
> >
> > It looks to be that it was removed already, somewhat behind schedule, in
> > commit 9470565579f29486f4ed0ffa50774268b64994b0 after an initial attempt
> > was made in commit 3abf024d2abb79614d8c4cb25a70d5596f77d0ad.  I don't
> > know if there is a procedure for bringing it back but I would guess it's
> > a call for the x86 maintainers. I imagine they will want to at least
> > know;
> >
> > 1. Why do you need init_mm exported?

In brief, my module use hardware virtualization technologies (only Intel ones 
for the moment) in order to prevent the kernel from behaving maliciously 
(because of a kernel malware) and to prevent the installation of many kernel 
malwares. One of my approaches is to preserve some kernel-constrained objects: 
for instance, some simple objects like idtr, gdtr, ... or some more 
complicated objects like the kernel address space layout, ...
For the latter I use init_mm.pgd.

I wrote a paper and will talk about it at the EICAR conference (May 11th and 
12th) this year (http://www.eicar.org/conference/index.htm).

> > 2. Is there an alternative approach to using init_mm?

I don't really take the time to think about another approach, but it seems 
natural to access to init_mm.pgd. Maybe, I could access to it by other means,  
but that would certainly be ugly :/

> > 3. Assuming yes, what are the downsides?

ugliness ;) maybe kernel version dependent.

> > 4. When do you think the module will be ready for posting?  i.e. is this
> >    really something destined for mainline or some perma-out-of-tree?

It is destined for mainline as far as I'm concerned. But it needs to be 
accepted by the kernel community when it will be ready.
(I work for a french public laboratory, so it will be GPL 2 or 3 licensed 
anyway)

>
> yes, those questions have to be answered.

I hope to have adequately answered to your questions.

Best regards,

	Eric

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