A 5mb binary blob in the kernel?

If you pop over to the NVIDIA web site and download the 3d card drivers for Linux, you'll note that there is a /usr/src/nv directory. In that directory is source code to the "thin layer" to the Linux kernel which NVIDIA links their binary blob. This, of course, makes no legal difference - NVIDIA are still extending the Linux kernel and therefore it is unlawful to distribute the Linux kernel along with the NVIDIA drivers, but NVIDIA doesn't do that, so it's not a problem - for them. Anyway, that's a side issue. I was thinking, recently, about the Linux kernel's "tainted" flag. Essentially, whenever you install a kernel module that isn't under some accepted open source license, the kernel sets a flag so that developers know there is a chance that any bugs you report might have been caused by code they can't fix. In general, this is not such a big deal as kernel modules are typically small and easy to isolate. The NVIDIA graphics drivers, on the other hand, are not small, they are actually over 5 meg.. loading anything that is 5 meg in size into the kernel is typically a bad idea. It's much better to split some parts out into userland and use thunks to connect the kernel part to the userland part.

So back to this /usr/src/nv directory. If you have a look, there's a bunch of source files, header files, make files and this nv-kernel.o file. That's the binary blob. They don't give us source for that bit. For me, it's 5104332 bytes, and most of the symbols have been replaced with stuff like _nv003299rm. This, of course, is to make it harder to understand if you were to try to reverse engineer it.

Now, someone out there, if you build your own kernel, I need your help (done, see comments). Go into the /usr/src/nv directory, do a make and get this thing to build. You may have to screw around with paths and stuff, and this is the reason why I havn't done it myself. Ok, got it to build? Great. Now make clean and remove the nv-kernel.o from the Makefile, then make. You should get some errors.. in particular, we're looking for "undefined symbol" errors. How many symbols are undefined?

This tells us how big the interface is between the source layer and the binary layer. If this interface is small enough we can write thunks for each symbol and move the binary layer into userland. If we do speed tests and discover that it isn't much slower to run the blob in userland then we can create a module that contains no binary code, and maybe the Linux kernel developers will consider this "untainted" enough that it is useful to someone. Knowing that interface will also help reverse engineer the binary part.

Comments

  1. QuantumG10:02 PM

    Well, it would appear that the interface for the "resource manager", nv_rdtsc, and pNVRM_ID are the only symbols needed from nv-kernel.o. The prototypes for these functions are defined in nv.h and pNVRM_ID is just a const char * used in nv.c. Here's the full list:

    "rm_disable_adapter"
    "rm_init_rm"
    "rm_read_registry_dword"
    "rm_set_agp_bitmap"
    "rm_free_unused_clients"
    "pNVRM_ID"
    "rm_get_device_name"
    "rm_teardown_agp"
    "rm_update_agp_config"
    "rm_free_agp_bitmap"
    "rm_isr_bh"
    "nv_rdtsc"
    "rm_shutdown_adapter"
    "rm_write_registry_dword"
    "rm_validate_pfn_range"
    "rm_i2c_remove_adapters"
    "rm_shutdown_rm"
    "rm_init_agp"
    "rm_isr"
    "rm_clear_agp_bitmap"
    "rm_is_legacy_device"
    "rm_run_rc_callback"
    "rm_free_agp_pages"
    "rm_ioctl"
    "rm_init_adapter"
    "rm_free_private_state"
    "rm_i2c_read_buffer_only"
    "rm_power_management"
    "rm_set_interrupts"
    "rm_get_vbios_version"
    "rm_init_private_state"
    "rm_alloc_agp_bitmap"
    "rm_alloc_agp_pages"
    "rm_i2c_write_buffer_only"

    ReplyDelete
  2. QuantumG2:58 PM

    Of course, another way to do it is to make a test harness for the nv-kernel.o file. I recently did this for the purpose of testing a decompilation. This way you get all the symbols that nv-kernel.o imports as well as the ones it exports. If anyone wants the test harness, you can grab it here: http://rtfm.insomnia.org/~qg/nv_test_harness.tar.gz

    ReplyDelete
  3. QuantumG2:59 PM

    If you'd like to help me work on the decompilation, email me: qg@biodome.org

    ReplyDelete
  4. Generic Viagra1:43 AM

    Hi people!
    I have been trying to get rid the boring feeling I was suffering for such a long time. Nevertheless, just have realized that this column is pretty worthy! then, I am so pleased of have read it.
    Thank you so much for sharing this fact of matter.

    ReplyDelete

Post a Comment

Popular posts from this blog

Disabling OS-X Device Removal Warnings In Yosemite

Image
If you're anything like me you've probably seen the Disk Not Ejected Properly message so many times that you've forgotten how annoying it is.. despite the fact that you never even wrote anything to the usb drive that you're yanking out of your Mac the operating system insists that you remove it "correctly". You're supposed to click the eject button. Why? I dunno, Apple seems to think that if you can write to it then the operating system might have written to it - and being Apple, they probably have. Well ya know what? Fuck you, I won't do what you tell me. Note: this will not fix your external drive disconnecting when your Mac goes to sleep. For that problem try disabling "put hard drive to sleep when possible" in both the Battery and Power Adapter tabs of the OS energy saver settings. What appears below is a dirty hack for deliberately removing a warning that Apple insists on showing you every single time you yank out a usb stick.
Read more

Rebirth Of The Spaceship

Image
Over the last year the space advocate community has splintered into two major groups in answering the question "where should we go next?" Moon First or Mars First . This division was present in the Review of Human Spaceflight (aka Augustine) committee's final report in late 2009, with the surprising conclusion that there isn't the funds for either, suggesting a number of intermediate destinations first - including asteroids. However, as few people consider asteroids to be truly interesting destinations for the human utilization of space ( except me! ), the debate rages on. Many Moon First advocates are "Mars Next" advocates while most Mars First advocates are "Moon Again?" detractors. The former claim that Mars exploration will benefit from lunar exploration, particularly in experience and risk reduction, and perhaps the procurement of propellant. The latter claim that lunar exploration is just a distraction and want to avoid the risk of be
Read more

Mars Direct Without Super Heavy Lift

Image
For a decade or two now the proponents of Bob Zubrin's Mars Direct have been bemoaning the lack of super heavy lift (any vehicle that can lift more than 50 ton to LEO). While few advocates claim a heavy lift launch vehicle is the only component of the Mars Direct plan which is missing, most consider it a necessary prerequisite. Before I tell you why I think that's simply wrong, let's just make a quick list of all the other things we still need: decent life support, space suits for Mars, rovers that run on methane/LOX, the ISRU propellant production system, bigger entry/descent/landing systems than have ever been flown, portable field equipment for the science mission, artificial gravity generation, and the habitat itself. Oh yeah, and a space rated nuclear reactor. The beautiful innovation of the Mars Direct plan was the use of the Mars atmosphere to produce the return propellant so it doesn't need to be carried all the way from Earth. Without this simple idea t
Read more