RE: [Fault-injection-developer] How is the patched insmod making module_list available
Status: Alpha
Brought to you by:
rustyl
Menu
▾
▴
RE: [Fault-injection-developer] How is the patched insmod making module_list available
|
From: Wang, S. <sta...@in...> - 2002-10-25 02:10:09
|
Please check my comments :)
And you can get more information from "FITH/doc/interceptor_lld.pdf".
> -----Original Message-----
> From: Lynch, Rusty=20
> Sent: 2002=E5=B9=B410=E6=9C=8825=E6=97=A5 2:35
> To: Wang, Stanley; Lynch, Rusty
> Cc: 'fau...@so...'
> Subject: RE: [Fault-injection-developer] How is the patched=20
> insmod making module_list available
>=20
>=20
> yea, I've done a good job of confusing people. :-> Let me explain...
>=20
> (NOTE: The explanation is really long, so stay with me. At least =
this
> will give me a forum for expressing my thoughts while looking=20
> through the code base.)
>=20
> When I start examining a project, I tend to take a bottom's=20
> up approach where:
> 1. I immediately start greping through the source code to get=20
> a feel for the design
> 2. I then start attempting to build the project
> 3. I then start hacking at the source to prove or disprove my=20
> understanding
> 4. After all of this I start reading design documents.
>=20
> For people who tend to approach problems from a higher level=20
> looking down, this=20
> will seem very backwards. All of the above is just an=20
> explanation for why I am
> doing what I am doing... you could say it's a method to my madness.
>=20
> So... I'm looking through the FITH cvs tree, trying to get a=20
> feel for how things
> are laid out. I observer that:
>=20
> * There is a user space utility called ficl, that is rooted=20
> in FITH/src/ficl/.
> I can see that it is communicating with some FITH kernel=20
> module via ictl() on
> a character device. For now that is all I care to know=20
> about ficl since I=20
> believe our immediate work is in implementing the kernel=20
> side code in such a=20
> way that the Linux kernel hacker community will accept.
>=20
> * There is a kernel character device called fith_dm.o that is=20
> rooted in=20
> FITH/src/dm/. After poking around some I can see:
> - this is a device that houses the kernel side logic used=20
> by other kernel=20
> side fault injection
> - the "dm" in the name means "Decision Maker". I note to=20
> myself that
> maybe fi_logic or something on those lines would make a=20
> better name,
> but I feel that I should think about it some more.
> - all communication seems to be over ictl() calls
>=20
> * There is another kernel character device called=20
> fith_fakeirq.o that is=20
> rooted in FITH/src/fakeirq. After poking around some I can see:
> - The only thing this module does is export a function=20
> called "fith_getirq"
> which is a replacement for "request_irq" function call.
The "fith_getirq" is only used when you want to inject fault into =
module
during it is initializing.
Fakeirq will search the "irq_desc" directly when you want to replace a
running module's interrupt handler :)
>=20
> * There are a bunch of other kernel modules in their own=20
> directories rooted
> under FITH/src/intcpt/. After some searching I figure out=20
> that "intcpt" means
> "interceptor", and that each of the directories under=20
> intcpt implement some kind
> of kernel side code for intercepting the normal operation=20
> of kernel code in order
> to insert a fault.
> - There is a module named "fith_aslt.o" rooted in=20
> FITH/src/intcpt/aslt/. =20
> + I manage to find a translation for "aslt" and the=20
> promptly loose it, and make=20
> a mental note to find a better name.
> + The module seems to just export a function called=20
> "fith_ioremap" that is a=20
> replacement for "__ioremap".
Acturally, aslt is a agent for pf. Hence you can even register a WP =
that
watch
an unmapped address.
> - There is a module named "fith_dbp.o" rooted in=20
> FITH/src/intcpt/dbp/.
> + I find that "dbp" means "Dynamic Binary Patch", and=20
> imediately start
> looking for functionality the duplicates existing=20
> projects (like dprobes.)
> + The only thing the module appears to do is register a=20
> bunch of exit functions
> using the "hooks.c" implementation (otherwise known as=20
> "Kernel Hooks".)=20
> + I make a mental note to myself that this is where FITH=20
> is dependant on
> dprobes (or at least this is where FITH is dependent on=20
> deprobes dependencies),=20
> and that this will be an immediate blocker to getting=20
> FITH to compile on=20
> 2.5.x since I'm pretty sure the hooks.c implementation=20
> has changed=20
> dramatically (or just doesn't exist) in 2.5.x kernels.
> - There is a module named "fith_dr.o" that is rooted in=20
> FITH/src/intcpt/dr/
> + It looks like this module does something like=20
> "fith_dbp", but it's
> not obvious what the purpose of this module is at first glance.
> + This module has the same hook.c dependencies as fith_dbp.o.
> - There is a module named "fith_ovr.o" that is rooted in=20
> FITH/src/intcpt/override/
> + It appears to implement replacements for the normal=20
> input/output functions
> like inb/outb and such. The functions do not seem to=20
> be exported so I'm=20
> not sure how they are used. I'm also confused by the=20
> fact that all of the
> standard input/output functions are either macros are=20
> inline functions, so
> I'm not sure how a loadable kernel module could replace=20
> these functions.
We use fith_ovr no longer :)
Fith_ovr is only used in the initial version of FITH. (Version A)
If you want to use this interceptor, you must recompile your module =
with a
special
header file:) you can find a example in "FITH/test/src".=20
> - There is a module named "fith_pf.o" that is rooted in=20
> FITH/src/intcpt/pt/
> + It looks like this module implements a kernel hook for=20
> page faults, but
> I only casually glanced at the code.
> + I'm pretty sure dpobes does the same thing, and wonder=20
> if this isn't something
> that could be done using dprobes.
>=20
> * There is a patched version of insmod rooted in FITH/fith_insmod/
> + After poking around I figure out that this is the entire
> modutils v2.4.6 package, and that the only file that has been=20
> touched (other then a bunch of CVS symbols that were changed
> because we imported the source to our own cvs tree) was
> FITH/fith_insmod/insmod/insmod.c
> + I get a good feel for what the hacked up version of=20
> insmod is doing, and how
> it is using the kernel modules that I already discovered.
Our patch for insmod didn't impact its main workflow. We just
replace some instructions ("in/out") and two symbols ("ioremap" and
"request_irq").=20
Nothing else :)
>=20
>=20
> Ok, now I have some kind of a clue as to what this whole FITH source
> tree is trying to do. I compile the source on a RH7.3 system=20
> by following
> the instructions in the README and don't run into any=20
> problems. Now I start
> attempting to build on a RH8.0 system where I have been=20
> playing with a=20
> 2.5.44 kernel.
>=20
> The first thing I trip on is the lack of a kernel hook=20
> implementation, so
> I do a little research and find the whole kprobes vrs.=20
> dprobes discussion
> happening on lkml.=20
>=20
> I then start trying to build fith_fakeirq.o=20
> (FITH/src/fakeirq/) and run into
> all kinds of problems with hard coded assumptions in the FITH=20
> build scripts.
> Since I have already convinced myself that all of the FITH=20
> kernel could should
> build inside the Linux kernel tree, I move over fakeirq.c and=20
> the fith header
> files to the 2.5.44 kernel tree and do not give a second=20
> thought as to why
> I was seeing all the strange compile problems when building=20
> within the FITH
> source tree.
>=20
> The fakeirq.c code doesn't have the kernel hook dependencies=20
> as some of the
> other modules, so it seems like a good starting point. I'm=20
> able to build
> just fine, but have some symbol resolution problems. A=20
> couple of these=20
> are the symbols that the patch discussed in an earlier thread=20
> exports. I
> just hack the fith header file that depends on the both of=20
> these symbols
> and now the only unresolved symbol is "module_list".
>=20
> It takes me a while to figure out where module_list is coming=20
> from. None of
> the FITH code implements module_list, so it's not a=20
> dependency on one of the=20
> other FITH kernel modules. Then I notice that a symbol named=20
> module_list is
> used in the insmod utility. I suspect that maybe the hacked=20
> version of insmod
> provides the symbol so I try to load fakeirq.o with a patched insmod.
>=20
The "module_list" is introduced by "__MOD_INC_USE_COUNT". This Marco
is used in fith_lock_module, and this function is defined in
"FITH/include/linux/fith/fith_internal.h".
The "module_list" is not a exported symbol in vanilla kernel, and it =
will be
exported by Dprobes.
I've add some comments for this symbol in README.
> insmod fails because it can not open "/dev/fith", so I check=20
> out insmod.c
> and verify that if insmod.c can open /dev/fith, it will=20
> continue with loading
> the kernel module. insmod.c will attempt to do some dirty=20
> tricks on the module
> with the help of /dev/fith, but even if /dev/fith was really=20
> /dev/null insmod
> will still completely load the module and just print an error=20
> message about not
> being able to insert a fault set. So I trick insmod by=20
> making a /dev/fith node
> with major and minor numbers for /dev/null, and I convince=20
> myself that I am able=20
> to load fakeirq.o without running into problems with=20
> unresolved symbols.=20
>=20
> After looking into this some more this morning I realized=20
> that I was wrong, and=20
> that the patched insmod was not able to load the module, so I=20
> still do not know
> now module_list was supposed to be resolved. Maybe this was=20
> a symbol that existed
> in 2.4.x?
"module_list" exists in 2.5 also. It is defined in kernel/modules.c
So many thanks for your great and hard work :)
=20
Stanley
>=20
> What a long, lingering email.... if you made it this far the=20
> I must apologize for
> this horribly crafted email. :-(
>=20
> -rusty
>=20
>=20
> -----Original Message-----
> From: Wang, Stanley=20
> Sent: Thursday, October 24, 2002 12:56 AM
> To: Lynch, Rusty
> Cc: 'fau...@so...'
> Subject: RE: [Fault-injection-developer] How is the patched insmod
> making module_list available
>=20
>=20
> I've been totally confused.
> As I know, the fith_insmod depends on fith_dm, and fith_dm=20
> depends on all interceptors (includeing fith_fakeirq).
> So fith_insmod will return an error unless all FITH's modules=20
> have been loaded into kernel.
> Can you give me more information about the error you encounted, =
Rusty?
>=20
> Thanks :)
> Stanley
> -----Original Message-----
> From: Lynch, Rusty [mailto:rus...@in...]
> Sent: 2002?10?24? 10:52
> To: 'fau...@so...'
> Subject: RE: [Fault-injection-developer] How is the patched=20
> insmod making module_list available
>=20
>=20
> Actually, it's fakeirq.o, not fith_fakeirq. (hmm... maybe the=20
> build script that I tossed out the window is moving fakeirq.o=20
> to fith_fakeirq.o? It doesn't matter... I'm just getting a feel
> for the code.)
>=20
> * NOTE: Keep in mind I hacked out the need for the symbols your
> kernel patch was depending on.
>=20
> [rusty@penguin2 rusty]$ sudo /sbin/insmod fakeirq
> Using
> /lib/modules/2.5.44-ac2/kernel/drivers/faultinjection/fakeirq/
> fakeirq.o
> /lib/modules/2.5.44-ac2/kernel/drivers/faultinjection/fakeirq/
> fakeirq.o:
> unresolved symbol module_list
>=20
> I can add all kinds of unresolved symbols to a module and fith_insmod =
> is happy to install the module.
>=20
> -rusty
>=20
> -----Original Message-----
> From: Zhuang, Louis=20
> Sent: Wednesday, October 23, 2002 7:37 PM
> To: Lynch, Rusty
> Subject: RE: [Fault-injection-developer] How is the patched insmod
> making module_list available
>=20
>=20
> Rusty,
> Did you mean you can not insert fith_fakeirq by normal insmod?
>=20
> > -----Original Message-----
> > From: Lynch, Rusty=20
> > Sent: Thursday, October 24, 2002 10:17 AM
> > To: Zhuang, Louis; Lynch, Rusty
> > Subject: RE: [Fault-injection-developer] How is the=20
> > patched insmod making module_list available
> >=20
> >=20
> > What's there to log? /sbin/insmod fails because of an=20
> > undefined symbol, module_list.
> >=20
> > Although it looks like it has nothing to do with 2.5.44. =20
> > I think the patched insmod=20
> > just doesn't catch the fact that module_list is not=20
> > defined. Kind of a side effect?
> >=20
> > -rusty
> >=20
> > -----Original Message-----
> > From: Zhuang, Louis=20
> > Sent: Wednesday, October 23, 2002 7:11 PM
> > To: Lynch, Rusty
> > Subject: RE: [Fault-injection-developer] How is the=20
> patched insmod
> > making module_list available
> >=20
> >=20
> > We have not a try for 2.5.44... could you give us your=20
> error log?
> >=20
> > > -----Original Message-----
> > > From: Lynch, Rusty [mailto:rus...@in...]
> > > Sent: Thursday, October 24, 2002 10:02 AM
> > > To: 'fau...@so...'
> > > Subject: [Fault-injection-developer] How is the patched=20
> > > insmod making module_list available
> > >=20
> > >=20
> > > I'm checking out the code and trying to get fakeirq.c to=20
> > > compile with the
> > > 2.5.44 kernel, but have an unresolved symbol for=20
> > > "module_list" unless I use
> > > the patched insmod.
> > >=20
> > > What's up with that? It looks like all that was changed=20
> > > in the insmod
> > > source tree was insmod.c, and I don't see anything having =
> > > to do with
> > > "module_list".
> > >=20
> > > -rusty=20
> > >=20
> > >=20
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by: Influence the future=20
> > > of Java(TM) technology. Join the Java Community=20
> > > Process(SM) (JCP(SM)) program now.=20
> > > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
> > >=20
> > > _______________________________________________
> > > Fault-injection-developer mailing list
> > > Fau...@li...
> > > =
https://lists.sourceforge.net/lists/listinfo/fault-injecti
> > on-developer
> >=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future=20
> of Java(TM) technology. Join the Java Community=20
> Process(SM) (JCP(SM)) program now.=20
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
>=20
> _______________________________________________
> Fault-injection-developer mailing list
> Fau...@li...
> =
https://lists.sourceforge.net/lists/listinfo/fault-injection-developer
>=20
|
