Hacker News Reader

Comment by contingencies | Hacker News Reader

The reality is that the majority of systems out there use distribution vendor supplied kernels. If you are in this camp, note that one of the best things you can do for kernel security in production is run a custom kernel with all of the features you don't need removed.

If you go this route, definitely consider grsec as well.

Reasonably tuning your kernel can also offer speed (eg. via more specific CPU targeting), size and - critically for embedded environments - startup time improvements.

View on HN

> critically for embedded environments - startup time improvements.

This is so true. Back in the day when I was involve in embedded Linux development, the quickest bootup time was about 40secs. This was booting a v2.6 kernel in a minimum configuration on an ARM7 system over SPI NAND FLASH. Hopefully, the bootup time is in the subseconds by now. Are we getting to these speed yet?

"Hopefully, the bootup time is in the subseconds by now. Are we getting to these speed yet?"

You can do that[0] with minimal system. Actually, it's not that difficult to get booting time down to few seconds on most embedded systems. But in real world boot time highly depends on modules and drivers that must be loaded to make system up and running.

http://www.makelinux.com/emb/fastboot/omap

I'm working on a system which some decently advanced functionality booting a linux 3.14 kernel on an ARM. Currently I'm getting around ~5 seconds, from turning the power on to having the system fully loaded and ready.

I could possibly get it lower but it meets spec and any additional shaving off would probably require plenty of work while sacrificing debug-ability etc. so for now I'm fine where it is :)

> This is so true. Back in the day when I was involve in embedded Linux development, the quickest bootup time was about 40secs. This was booting a v2.6 kernel in a minimum configuration on an ARM7 system over SPI NAND FLASH.

The older NAND file systems were very slow. I've had a similar case where repartitioning the huge NAND into a smaller partition and only using a small partition reduced the boot time to 10 seconds without any other change. Modern UBIFS systems apparently don't have this problem.

As for subsecond boot times: no chance with Linux.

I've booted Linux in sub-second times using User Mode Linux so there's nothing actually preventing it other than the need to probe hardware in various slow ways, which could be improved.

So this is going from connecting power to having a full system ready to go?

The question doesn't really make sense since there's no "power" involved -- the kernel neither has nor lacks power... but if I understand the nature of the question, then the answer is "yes" -- the system goes from not existing to being at a bash prompt in under 0.3s on my laptop.

Just looked up what UBIFS is, and saw the reference to JFFS2. We tried JFFS, it was painfully slow. JFFS2 was emerging and tried that too. In reality, it did not really worked for booting up. Once it was up, it was pretty good. Unfortunately, we were developing a hand hand consumer electronics device, so boot up times were absolutely critical.

Since you mentioned majorities, how many Linux kernel systems out there belong to parties which can afford to maintain a custom-built kernel with things like grsec integrated?

Oh, wouldn't things be better if we had all that candy upstream?

There's Alpine Linux, which ships with a grsec-patched kernel. It is doing a great job and in fact has become due to its size the officially preferred Docker container base distro. I really wish more companies got behind it.

One thing I routinely do is compiling a monolithic kernel without module support (and exactly the modules the hardware needs). This way injecting a module into the kernel should be a little harder.

On a standard kernel you can still set kernel.modules_disabled=1 after everything you need is loaded. There should be no big difference in behaviour in both cases. Not that the module injection is common anyway...

Reply on news.ycombinator.com