My Own Private Binary: An Idiosyncratic Introduction to Linux Kernel Modules | Hacker News Reader

My Own Private Binary: An Idiosyncratic Introduction to Linux Kernel Modules

muppetlabs.com

In summary: The author developed a simple kernel module that implements a custom executable format (thus "my own private binary").

The kernel module does not check any binary meta data, instead it just checks for the file extension ("*.com"). There is no actual format, only a flat binary that is loaded into memory and executed, just like *.com executables on MS DOS.

This allows the author to create really tiny exectuables.

Love the muppetlabs posts.

See also this series on ELF binaries, and a really small (the smallest?) ELF executable.

http://www.muppetlabs.com/~breadbox/software/tiny/

What was the value in repeating the first few lines of the article?

I tend to look at the HN comments before reading an article, and I often enjoy other people's "See Also" suggestions. It helps me contextualize the material, which in turn is key to my learning from what I read.

Ah.. also, I usually scan these HN posts on my iPhone SE, a small screen, and I mark up the ones I might want to dig into, usually on a larger device. The Muppet Labs style is intentionally a very simple, text-heavy design, which is great for study but can be a tough wall o' text on my little phone.

I simply didn't catch that that first link, in the second paragraph, was a link to the ELF series.

Writing a kernel module for shits and giggles is a great intellectual exercise, but... Linux's binfmt_misc was designed for use cases like this, and configurably allows to run binaries in exotic formats with a user-mode loader/interpreter for them.

This misses the entire expressed point.

He explains why this is uninteresting and does not work toward his goal.

It just calls an interpreter, which is no better than any ordinary script except that you can supply a smaller interpreter than say bash, but no matter how small the interpreter, the binary plus interpreter is obviously and unavoidably larger than the binary alone.

Disclaimer for the sake of clarity: The "my" is part of the article name. I am not the author.

I didn't read this, but you should still read what I have to say about it, which is that it's wrong.

Also check out <restatement of something from the article>.

> A couple of people naturally pointed out that a shell script that did the same thing was much shorter than 45 bytes, to which my response was always that a shell script is not an executable, and if you want to consider scripts then you need to include the size of the interpreter binary along with the script size.

By the same reasoning, this article is cheating, since all you are doing is putting your interpreter binary in the kernel. So you have to add the size of your kernel module at least ;P

Not hard to write a "runcom" or the like loader entirely in userspace, btw.

> > a shell script is not an executable

By that measure, then a dynamically linked ELF binary is not an “executable” either, since it uses the dynamic linker ld.so to load itself.

Yeah, but the author does not use a dynamically linked executable.

My point is that by any reasonable definition, a shell script is an executable file, just as much as an ELF binary is. It might not be a binary executable, but still an executable.

Reply on news.ycombinator.com