Mike Rapoport fromIBM launched a bid to implement address space isolation in the Linuxkernel. Address space isolation emanates from the idea of virtual memory—where thesystem maps all its hardware devices' memory addresses into a clean virtual space sothat they all appear to be one smooth range of available RAM. A system that implementsvirtual memory also can create isolated address spaces that are available only to partof the system or to certain processes.
The idea, as Mike expressed it, is that if hostile users find themselves in anisolated address space, even if they find bugs in the kernel that might be exploited togain control of the system, the system they would gain control over would be just thattiny area of RAM to which they had access. So they might be able to mess up their own localuser, but not any other users on the system, nor would they be able to gain access to root levelinfrastructure.
In fact, Mike posted patches to implement an element of this idea, calledSystem CallIsolation (SCI). This would cause system calls to each run in their own isolatedaddress space. So if, somehow, an attacker were able to modify the return values storedin the stack, there would be no useful location to which to return.
His approach was relatively straightforward. The kernel already maintains a "symboltable" with the addresses of all its functions. Mike's patches would make sure that anyreturn addresses that popped off the stack corresponded to entries in the symbol table. Andsince "attacks are all about jumping to gadget code which is effectively in the middleof real functions, the jumps they induce are to code that doesn't have an externalsymbol, so it should mostly detect when they happen."
The problem, he acknowledged, was that implementing this would have a speed hit. He sawno way to perform and enforce these checks without slowing down the kernel. For thatreason, Mike said, "it should only be activated for processes or containers we knowshould be untrusted."
There was not much enthusiasm for this patch. AsJiri Kosina pointed out, Mike's codewas incompatible with other security projects like retpolines, which tries to preventcertain types of data leaks falling into an attacker's hands.
There was no real discussion and no interest was expressed in the patch. Thecombination of the speed hit, the conflict with existing security projects, and thefact that it tried to secure against only hypothetical security holes and not actualflaws in the system, probably combined to make this patch set less interesting tokernel developers.
It's one of the less pleasant aspects of kernel development. Someone can put a lot ofhours into a project, with no way to know in advance what objections might be raised atthe end. It wouldn't have been obvious to Mike and his colleagues that a speed hitwould be necessary. And the possibility of conflict with other existing kernel projectsis always very difficult to predict, especially since there often are workarounds thatcan be discovered only once members of the two projects start debating the variousissues in public.
OnlyLinus Torvalds' general reluctance to add security features that do not addressexisting security holes could have been predicted. He seems very consistent on thatpoint, much to the annoyance of security-minded developers throughout the Open Sourceworld. The idea of reducing the size of an attack surface seems self-evident to them;while to Linus, it seems self-evident that you shouldn't fix what isn't broken,especially where the fix adds bloat and increases the maintenance costs for the wholeproject. I think it's likely that even if Jiri and other developers had approved ofMike's patches, Linus might have objected later on.
Note: if you're mentioned in this article and want to send a response,please send a message with your response text to ljeditor@linuxjournal.com,and we'll run it in the next Letters section and post it on the website as anaddendum to the original article.
Zack Brown is a tech journalist atLinux Journal andLinuxMagazine, and is a former author of the "Kernel Traffic" weeklynewsletter and the "Learn Plover" stenographic typing tutorials. Hefirst installed Slackware Linux in 1993 on his 386 with 8 megs of RAMand had his mind permanently blown by the Open Source community. Heis the inventor of theCrumble pure strategy board game,which you can make yourself with a few pieces of cardboard. He alsoenjoys writing fiction, attempting animation, reforming Labanotation,designing and sewing his own clothes, learning French and spending timewith friends'n'family.
Recent Articles
