On Sat, Nov 07, 2015 at 08:53:29AM -0700, Mark Phillips wrote: > I liked the article a lot! It prompted me to buy "How Linux Works: What > Every Superuser Should Know" by > Brian Ward and it is a great read. I recommend it. > > My point is I disagree a little with Linus' goal of rejecting all security > patches if they slow down user space. Moore's Law is still in effect ( > http://www.techradar.com/us/news/computing/moore-s-law-how-long-will-it-last--1226772), > so the speed of computer hardware is still increasing faster than the drag > produced by software.
I agree ... but ... the real issue is that the hardware itself is insecure, and does not speed up security procedures as much as it should. Indeed, transistors are cheap and getting cheaper, and CPUs are now made with "dark silicon", functional modules that are only powered up as needed (like video rendering, or multiband radios). Frantically pursuing perfection in software without addressing the hardware weaknesses is like a vault door on a tent. So - who knows what is on your CPU chip? Or in the hard drive or flash drive controller, or the video chip, or ... Three modest proposals: 1) I would like to buy CPUs with netlists and corresponding maps of transistor layouts. I don't have time to scrutinize every chip I buy, but students being trained to design the next generation of chips do. I would love to donate to a fund that provides full ride scholarships to any student who finds an important functional difference between an actual chip, the netlist, and the functional description. 2) I would provide all data interfaces on a chip with unalterable counter registers that count every byte that passes through that interface since chip reset. Then I would put double entry bookkeeping in software and the kernel. It is not difficult to keep track of every byte that goes in and out the ethernet port, for example. Discrepancies between what programs are supposed to produce and what they actually produce indicate hanky panky. 3) CPU chips should have specialized dark silicon math units which perform large integer modulo arithmetic - a common component in most encryption algorithms. These math units need not be fast - just faster than bigint math in software. This saves power, and RAM space, and mistakes, and can run in parallel with other operations, so it would not slow the kernel, except for the instructions to load and unload it. (2) and (3) would require attention from the kernel, but it would be new standardizable hardware that Linus might find amusing to write code for. (1) would also lead to time-saving standardization - more good ideas get copied, and Linus's job gets easier. We do not need to do this on all CPUs - but most data center CPUs run Linux, and we can encourage Intel to differentiate those products with Linux friendliness and built-in security. BTW, I am a chip designer. Though I do not design CPUs, I have some idea of what is possible. Keith -- Keith Lofstrom [email protected] _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
