The plethora of solutions to this problem that are already out there, battling through the usability issues, leads me to a perilous thought: there really aren't any guarantees that .. not only do we have the NSA to deal with, but .. many other groups which can profit from severe fragmentation. Cocktail OS builds for commodity hardware are one thing, but knowing - truly - what is going on in the stack is another thing entirely. I think thats important, for an Open Source Wifi/Network effort.
So any attempt to make an open source router OS that kicks ass, should, in my opinion, predominantly strive to be a self-hosting OS, with full sources on-board, and signed images being turnkey; i.e. everything needed to build the OS from source is part of the package; i.e. no cross-compiling, no binary blobs, the router builds its own firmware.
Yes, its extreme, but I truly do think that the disconnect between build-ability and OS 'dependencies management tools' has a lot to offer in terms of improvement. If the first thing the machine did, OOBE, was to build itself its own unique system image .. from source .. as a feature for the user .. then we have a secure system.
Unsigned system-image keys are going to be very, very much more important in this networking/communication space. Full source->build->signed-binary control as part of the bootup is where this effort should focus. Sign the code, build the code, sign the binaries, only run signed binaries on the OS built around the key, and so on.
This allows intercommunication - shared Source, of course - but it also allows audit of things in the environment which is being defended. If we don't build-in sufficient encryption to make it truly safe, whats the point of being so Open about it? Imho, RouterOS should be full-Source onboard.
As a practical matter, consumer routers can't be self-hosting. They don't have the processing power, memory, and storage necessary, and none of the router vendors can be trusted to not have some kind of embedded rootkit that circumvents all of that. It's far better to work on having a deterministic verifiable cross-compiling build system and continue to flash the firmware over JTAG.
>They don't have the processing power, memory, and storage necessary
This is in my opinion, a sign of bloat. They darn-well do have the processing power to build their own images! Its just 'not desirable to use a slow computer to do it' ..
Well, where the build is slow: refactor until its fast.
> It's far better to work on having a deterministic verifiable cross-compiling build system and continue to flash the firmware over JTAG.
The new open networks will require a lot more crypto. I'd prefer to run an open network where signed binaries and such things are just part of the norm. But then, this is all just hot-air .. time better spent actually working on the problem of so much hardware, so little actually safe source code to run on it.
In theory you can strip out the majority of the kernel sources and I'm sure there's some automated way to do this with the kernel build process. Make already doesn't even have to look at the source for drivers that aren't being built. I think there's a lot of macros that depend on the config but there should still be a way to basically run the preprocessor over everything being compiled to strip out all of the pointless #ifdef blocks.
The preprocessor's got nothing to do with it. As you've noted, the raw size of the source code is easily dealt with. (At least for parsing. We still haven't identified where it's being stored in the first place.) The problem is that when targeting an embedded system, you really want to use compiler optimizations (especially size optimizations), and those heuristics require more RAM than routers have. Ideally, you would compile large parts of the OS with link-time optimization, which is one of the most memory-intensive options you can pass to a compiler.
So any attempt to make an open source router OS that kicks ass, should, in my opinion, predominantly strive to be a self-hosting OS, with full sources on-board, and signed images being turnkey; i.e. everything needed to build the OS from source is part of the package; i.e. no cross-compiling, no binary blobs, the router builds its own firmware.
Yes, its extreme, but I truly do think that the disconnect between build-ability and OS 'dependencies management tools' has a lot to offer in terms of improvement. If the first thing the machine did, OOBE, was to build itself its own unique system image .. from source .. as a feature for the user .. then we have a secure system.
Unsigned system-image keys are going to be very, very much more important in this networking/communication space. Full source->build->signed-binary control as part of the bootup is where this effort should focus. Sign the code, build the code, sign the binaries, only run signed binaries on the OS built around the key, and so on.
This allows intercommunication - shared Source, of course - but it also allows audit of things in the environment which is being defended. If we don't build-in sufficient encryption to make it truly safe, whats the point of being so Open about it? Imho, RouterOS should be full-Source onboard.