[unused symbol] need to use init_mm

[unused symbol] need to use init_mm

[Eric Lacombe]

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,

	Eric

Re: [unused symbol] need to use init_mm

[Mel Gorman]

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?
2. Is there an alternative approach to using init_mm?
3. Assuming yes, what are the downsides?
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?

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [unused symbol] need to use init_mm

[Ingo Molnar]

* Mel Gorman <mel@csn.ul.ie> 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?
> 2. Is there an alternative approach to using init_mm?
> 3. Assuming yes, what are the downsides?
> 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?

yes, those questions have to be answered.

	Ingo

Re: [unused symbol] need to use init_mm

[Eric Lacombe]

On Thu, Apr 30, 2009, Ingo Molnar wrote :
> * Mel Gorman <mel@csn.ul.ie> 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

Re: [unused symbol] need to use init_mm

[Mel Gorman]

On Thu, Apr 30, 2009 at 07:55:54PM +0200, Eric Lacombe wrote:
> On Thu, Apr 30, 2009, Ingo Molnar wrote :
> > * Mel Gorman <mel@csn.ul.ie> 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.
> 

If it's the kernel portion of the address space is what you care about,
is current->mm->pgd usable?

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

Unfortunately, you are already hit with the kernel version problem as
2.6.29 has been released without init_mm exported for the x86 arch.

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

If it really is absolutly necessary that you have init_mm and the
alternatives really are too ugly, patch 1 of your set becomes a
re-export of init_mm. The leader of that patch should explain why the
alternatives to init_mm suck.

You can try posting a patch to export init_mm without an in-tree user but
I wouldn't bet money on the x86 maintainers picking it up without an
extremely compelling reason.

> >
> > yes, those questions have to be answered.
> 
> I hope to have adequately answered to your questions.
> 

We can't go back in time so check out if current->mm->pgd will do the job. If
not, make patch 1 of your set a re-export of init_mm until you're ready to
post. At that point, people can see what you are doing and suggest what an
alternative might be or if indeed the symbol should be exported after all.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [unused symbol] need to use init_mm

[Eric Lacombe]

Le vendredi 1 mai 2009 17:51:30 Mel Gorman, vous avez écrit :
> On Thu, Apr 30, 2009 at 07:55:54PM +0200, Eric Lacombe wrote:
> > On Thu, Apr 30, 2009, Ingo Molnar wrote :
> > > * Mel Gorman <mel@csn.ul.ie> wrote:
> > > > On Thu, Apr 30, 2009 at 12:32:04PM +0200, Eric Lacombe wrote:

[...]

> If it's the kernel portion of the address space is what you care about,
> is current->mm->pgd usable?

Not currently, because this one is precisely compared to init_mm.pgd.

[...]

> > > > 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)
>
> If it really is absolutly necessary that you have init_mm and the
> alternatives really are too ugly, patch 1 of your set becomes a
> re-export of init_mm. The leader of that patch should explain why the
> alternatives to init_mm suck.
>
> You can try posting a patch to export init_mm without an in-tree user but
> I wouldn't bet money on the x86 maintainers picking it up without an
> extremely compelling reason.

Thanks for your comments. I recently thought about an alternative that seems 
to be acceptable.
Nonetheless, I need to modify my security paradigm a little, but this one will 
still be correct. Besides, no ugliness ;)

Best regards,

	Eric