System.map available?

[maikthulhu]

We're working on throwing together a module for internal testing but one of the kernel modules we're using requires locations of certain functions in the kernel.  Usually it just probes /proc/kallsyms but that's not available in the default kernel config.  I want to avoid rebuilding the kernel with CONFIG_KALLSYMS because it's one more thing we'd have to maintain when all we really need access to is the global symbols map.  Any chance System.map is available somewhere in the build system repo I can go fetch it from?

[curaga]

It's not publicly posted, as having it available is considered a security issue - knowing the locations of the functions may allow compromising the kernel more easily. Can you elaborate what you need it for?

[maikthulhu]

Our goal is to use chipsec (https://github.com/chipsec/chipsec) in automated functional testing to evaluate the security of computers we manufacture.  One of the components is a kernel module which takes the addresses of raw_pci_read, raw_pci_write, and page_is_ram as parameters at load time.

I didn't realize this could be viewed as a security issue.  Any help you can provide is appreciated.

[curaga]

According to https://github.com/chipsec/chipsec/pull/29 the latest source only requires the page_is_ram function, no longer the two pci ones. That function alone shouldn't expose too much, so here's the address for that for the 7.x 32- and 64-bit kernels:

Code: [Select]

4.2.9-tinycore64:ffffffff8106c85e W page_is_ram
4.2.9-tinycore:c013c3ce W page_is_ram
Let me know if you need some other version's.

[maikthulhu]

Awesome!  I'll convince the other team to use the latest version.  Thanks for your help.

[maikthulhu]

I've tried a few different things but I can't get it to load by passing that address.  You're supposed to just insmod chipsec.ko a1=0xdeadbeef but it says "unknown symbol in module, or unknown parameter".  It does the same thing if I don't pass any parameters as well so I can't be sure it's not the right address.  The kernel I'm using is from http://tinycorelinux.net/7.x/x86_64/release/distribution_files/vmlinuz64 - that's what we're looking at, right?  Just want to make sure I'm not crazy.

[curaga]

dmesg should show what the unknown symbol was. That's the correct kernel.

The code disables the a1 parameter when using a recent enough kernel version, so I guess you need to edit that check, but that's not your current issue if the module doesn't load.

[maikthulhu]

Yeah I saw that check and tried forcing it to use a1 anyways just to see what happened, no dice though.  What I'm doing to build the chipsec module is pulling down linux-4.2.9-patched.txz, extracting it to a temp folder, copying the kernel config in, then make oldconfig && make prepare && make modules.  Once that's done I modify the Makefile under chipsec/drivers/linux to point it to tmp/src/linux-4.2.9 instead of /lib/modules/`uname -r`/build, then I type make and it generates the chipsec kernel module.

It feels weird since I'm having to build all new kernel modules, and I'm not entirely clear what the dependency on having to build the modules from source is.  If it's just looking for Modules.symvers (which is also available in the distribution files repo), can I just put that somewhere and be done?  Seems like me building the modules could potentially put the symbols in a different place than the ones that are actually running from corepure64.gz.  Obviously I'm not entirely sure what's happening here but feel like I have a good idea, just trying to fill in the pieces.

[maikthulhu]

I forgot to take a look at dmesg like you mentioned.  I was getting chipsec: Unknown symbol kallsyms_lookup_name.  I decided to start over with the chipsec git repo and followed their "don't install just run" instructions.

Now when it tries to load the kernel module it gives me "Operation not permitted" (not passing a1 at this time).  dmesg now states "Chipsec find_symbols failed.  Unloading module".  I grepped through the chipsec source and found that error in chipsec_km.c under int find_symbols().  It includes an #ifdef where if kernel version is <= 2.6.33 it uses the a1 parameter passed in on load, else it uses kallsyms_lookup_name("page_is_ram") to get the location.  If that result is 0 then it errors out and prints the message above.

I take the above to mean that, for whatever reason, the previous build of chipsec.ko had trouble locating kallsyms_lookup_name.  Now it seems to able to run the function but trying to find the location of page_is_ram is failing.

[maikthulhu]

I got it to work.  chipsec_km.c was assuming if kernel version was over 2.6.33 it would have kallsyms_lookup_name(), but that function still requires CONFIG_KALLSYMS=y.  I modified the #if to force it to use the a1 parameter, placed the page_is_ram symbol definition in a System.map file, and told chipsec/helper/linux/helper.py to grep /path/to/System.map instead of /proc/kallsyms for the page_is_ram location.

This worked beautifully once I understood what was going on and I want to thank you again for your help.