Community Notebook Kernel News Zack’s Kernel News

Chronicler Zack Perl Dependencies Arnd Bergmann looked over the whole Rob Landley has not had much luck with his patch and said he couldn’t find any show- Brown reports on patches to remove Perl as a kernel build de- stoppers and felt that James’s work was the latest news, pendency. As he pointed out recently, the ready to go into the 3.9 kernel. 2.6.25 Linux kernel added some Perl scripts to The more interesting discussion in this views, dilemmas, the build system. This means that anyone thread turned out to be about kernel develop- wanting to compile Linux since version ment processes. For example, James’s initial and developments 2.6.25, would have to have Perl installed on patch-set was based on the linux-next tree. within the Linux their system. Before the 2.6.25 kernel, that This probably seemed sensible to him, be- was never required. Rob’s patches replaced cause he was submitting his code to be in- kernel community. the Perl scripts with simple Unix shell scripts. cluded in that tree. But Stephen Rothwell ex- But – as he said in his email – he’s posted plained that, no, kernel development should By Zack Brown these same patches over and over, and be based on Linus Torvalds’s official tree. The they’ve never been picked up. linux-next tree was essentially just a reposi- Andrew Morton wrote back, saying he didn’t tory for things on their way into Linus’s tree see why a Perl dependency would be a prob- and shouldn’t be considered a development lem for anyone. He pointed out that any deci- target on its own. sion to remove Perl dependencies would also James pointed out that his port depended necessarily include a commitment to remove on code that only existed in the linux-next all *future* Perl dependencies, which might tree and hadn’t been merged into Linus’s offi- take a bit of work and diligence. He asked cial tree yet. He asked if the right approach what Rob’s overall reasoning was for these would be to snarf those parts of linux-next patches. into his own tree to keep his code working Rob replied, “it’s a completely gratuitous and just feed it back to Stephen that way. build environment dependency, and the kernel Stephen replied that, yes, that would be ap- has a history of removing those.” He also propriate, if the code in linux-next was a real added that his shell scripts were at least as dependency and not just a conflict that simple, if not simpler, than the Perl scripts they James’s patch would resolve. Stephen said replaced. So, accepting his patches would not that if James’s patch conflicted with code in li- only remove the dependency, it would also nux-next, he should just never mind about the simplify the kernel. conflict and let either Stephen or Linus resolve Rob added that cross-compiling – already a it themselves at merge time. But, if James’s tricky proposition – was also made more error- code legitimately depended on code in linux- prone by having a Perl dependency. next, James could feel comfortable snarfing it There was not much discussion on the mail- into his tree – but Stephen exhorted James to ing list. But clearly, there’s resistance to re- let the relevant maintainers know that he ex- moving the Perl dependency. Rob has submit- pected their trees not to be “rebased.” ted these patches at least half a dozen times, Rebasing is when you use Git to merge one and each time they fell on the floor. branch of development with another, by “re- My sense is that there must be a significant playing” the patches from one branch, di- group of kernel developers who want to use rectly onto the other, and then discarding the Zack Brown Perl in the build environment, or else some- merged branch. When you rebase, you’re The Linux kernel mailing list thing like Rob’s patches would be a no-brainer. changing the history stored in your Git repos- comprises the core of Linux Clearly, fewer build dependencies are better itory. If you’re pushing your tree to anyone development activities. than more, unless the build dependency is ac- else, this could result in unnecessary merge Traffic volumes are immense, tually important. conflicts. Hence, Stephen’s advice to James. often reaching 10,000 Stephen replied that his linux-next depen- messages in a week, and dencies were actually trivial, and he could keeping up to date with the Coding for linux-next entire scope of development James Hogan posted some patches to port easily resubmit his patches without those de- is a virtually impossible task Linux to Imagination Technologies’ Meta ATP pendencies, to make life easier. He said he’d for one person. One of the and HTP processor cores. These are multi- reintroduce those changes later. few brave souls to take on threaded, general-purpose CPUs that are often There was also the question of when some- this task is Zack Brown. used in digital radios. one should consider their code “ready” to

92 June 2013 Issue 151 linux-magazine.com | Linuxpromagazine.com Community Notebook Kernel News

submit to the linux-next tree. Stephen was completely stupid. And, he added not be able to control how a Linux sys- answered simply – if it’s ready to go into that “getting me to care about some ven- tem is used by the user. The user should Linus’s main tree, it’s ready to go into li- dor that ships external binary-only mod- be the ultimate authority; and any key- nux-next. The linux-next tree is entirely a ules is going to be hard as hell.” signing features going into the kernel staging area for code that’s on its way to The debate continued for quite a should focus on providing the user with Linus. while. A significant portion of it involved the security features they want. Security technical considerations of various other features should never prevent the user MS Key Blessings ways of dealing with the secure boot from doing something that violates the The Windows 8 “secure boot mode” mode key-signing issue. But all of these wishes of that distribution or other third controversy is encroaching into kernel considerations boiled down to dealing party. development. David Howells of Red Hat with the fact that certain hardware in- Matthew replied to Linus’s argument, posted some patches that would allow cluded these “secure boot” features and saying, “The user Microsoft cares about Linux kernels running in secure boot that Microsoft held the keys to that par- isn’t running Linux. The user is running mode to load new cryptographic keys ticular kingdom. Windows, and someone’s merely using dynamically that had been signed by Mi- At one point Greg Kroah-Hartman said, Linux as a vector to launch their back- crosoft. “I fail to see how Microsoft should be doored Windows kernel. How do Micro- Microsoft would apparently only sign dictating how Linux, or any other operat- soft protect that user? They blacklist the runnable EFI PE binaries, so David’s ing system, works, especially when they signature used by that Linux bootloader. code implemented some data wrapping aren’t even signing the kernel, they are If we want to protect the user’s ability to and file-parsing shenanigans to deal with merely signing a bootloader shim and boot Linux, we need to protect the Win- that under Linux. He asked Linus Tor- saying ‘do your best for keeping the rest dows users from hav- valds to pull the patch-set. of the system secure please.’” ing Linux used Linus, however, replied, “Quite At around the same time, Linus reen- against them.” frankly, this is f*cking moronic. The tered the discussion with a clearer state- whole thing seems to be designed ment of principle. Ultimately, he said, around stupid interfaces, for completely any Linux security features had to moronic reasons. Why should we do have the central characteristic of this?” protecting the user. And, specifi- Matthew Garrett replied that Microsoft cally, he said to Matthew, was the only signing authority for these “The whole and only rea- keys, and they refused to sign anything son I ever merged but runnable EFI PE binaries; so Linux module signatures is would have to handle that case. because it actually Linus replied that Red Hat could get in allows *users* to bed with Microsoft if it wanted, but that do a good job at he saw no reason why any of their key- security. You, on signing code had to live in the kernel. He the other hand, said, “We support X.509, which is the seem to have standard for signing. Do this in user land drunk the cool- on a trusted machine. There is zero ex- aid on the cuse for doing it in the kernel.” He whole ‘let’s added, “It’s trivial for you guys to have a control the signing machine that parses the PE bi- user’ crap.” nary, verifies the signatures, and signs This seems the resulting keys with your own key.” to be the main Matthew wasn’t happy about the situa- distinction tion either, but he argued that vendors Linus draws in wanted to ship keys that had been signed this case. He by a trusted party and that, for the mo- seems to feel ment, it seemed that Microsoft was that that, fundamen- trusted party. tally, distribution Linus replied that the whole idea that vendors and other only Microsoft’s keys could be trusted, third parties should

linux-magazine.com | Linuxpromagazine.com Issue 151 June 2013 93 Community Notebook Kernel News

Linus said that none of that mattered. Sure, users will screw that up too. Thomas said that this whole mess He told Matthew, “Stop arguing about They’ll want to load crazy nvidia bi- would be replaced by only two user-visi- what MS wants. We do not care. We care nary modules etc crap. But make it ble states: CPUHP_PREP_, about the *user*. You are continually *their* decision, and under *their* for setting up and freeing the needed missing the whole point of security, and control, instead of trying to tell the data structures, and CPUHP_ENABLE_, for enabling and disabling facili- about what MS wants you to do. It’s ir- blessed by Microsoft. ties. relevant. The only thing that matters is Because it really shouldn’t be The rest of Thomas’s “state machine” what our *users* want us to do, and pro- about MS blessings, it should be would be entirely invisible to the user tecting *their* rights.” about the *user* blessing kernel and could be dealt with later. As Rusty A little later, Linus outlined more of modules. Russell put it, “Episode II is where we what he thought Linux security should Quite frankly, *you* are what the collapse each into sane states as Thomas be: key-hating crazies were afraid of. You clarified. That can be reviewed: I’d hate peddle the ‘control, not security’ to try to do it in one go.” “Instead of pleasing microsoft, try to crap-ware. The whole ‘MS owns your see how we can add real security: machine’ is *exactly* the wrong way Kernel.org Post-Breach • a distro should sign its own mod- to use keys.” Workflow ules AND NOTHING ELSE by de- The kernel.org security breach from back fault. And it damn well The debate continued on a number of in August of 2011 is still affecting the shouldn’t allow any other mod- different technical levels for a long time. workflow of certain kernel developers. ules to be loaded at all by de- But, it seems that Linus has very clear After the kernel.org admins locked down fault, because why the f*ck opinions about allowing keys that prevent all services, they reimplemented only a should it? And what the hell the user from controlling their own sys- subset of the features they’d offered be- should a microsoft signature tem. My sense is that there’s virtually no fore the break-in, and in particular they have to do with *anything*? chance that David’s code – or anything re- would only give accounts to users who • before loading any third-party sembling it – might get into the kernel. could verify their identify by a signed module, you’d better make sure cryptographic key. you ask the user for permission. Hotplug Cleanup/​Recoding Recently, Paul Gortmaker noticed a On the console. Not using keys. Thomas Gleixner reported that the CPU bunch of new files in the Documentation Nothing like that. Keys will be hotplug implementation had been grow- directory of the kernel source tree that compromised. Try to limit the ing gradually monstrous, with a variety were not represented in the 00-INDEX damage, but more importantly, of races, undocumented behaviors, and file in that directory. He posted a patch to let the user be in control. other insanity. He posted a set of patches bring the file up to date. • encourage things like per-host to rework the entire thing, creating a pre- Rob Landley replied, “I’ve got a script random keys – with the stupid dictable state machine that would pro- that makes html navigation pages from UEFI checks disabled entirely if vide symmetry to the startup and tear- the 00-INDEX files and another one that required. They are almost cer- down process. parses that to find dead links in both di- tainly going to be *more* secure Linus Torvalds had some criticisms of rections. (Files with no 00-INDEX entry than depending on some crazy the patch. In particular, he wanted to and 00-INDEX entries that don’t refer to root of trust based on a big com- make sure that Thomas went all the way a file.) I haven’t run it in forever because pany, with key signing authori- and didn’t hold back. Linus apparently the kernel.org guys took everybody’s ac- ties that trust anybody with a *hated* the current hotplug implementa- counts away, and they won’t give me a credit card. Try to teach people tion and felt that a lot of hotplug behav- new .ssh key without a blood test or about things like that instead. ior should not be exposed to the user at some such, and even if I did jump Encourage people to do their own all, but just kept tucked away behind the through the hoops they made ssh go to a (random) keys, and adding scenes where it could be quietly eradicated. git wrapper you can’t rsync through, so I those to their UEFI setups (or This was Thomas’s goal as well. In can’t update kernel.org/​doc/​Documenta- not: the whole UEFI thing is particular, he reassured Linus that the tion anymore.” more about control than secu- hotplug notifier chains would be re- He added, “I have buckets of things I rity), and strive to do things like moved entirely, along with the myriad want to do to this directory but no longer one-time signing with the private untraceable user notifier implementa- have a kernel account. *shrug*.” key thrown out entirely. IOW try tions that had grown like lichen around My personal opinion is, I can see why to encourage *that* kind of ‘we the hotplug code. As he put it, “The cur- developers might be unhappy at having made sure to ask the user very rent hotplug maze has 100+ states that to change their workflow – but at the explicitly with big warnings and are completely undocumented. They are same time, most kernel contributors do create his own key for that par- asymmetric vs. startup and teardown. simply post patches to the mailing list ticular module’ security. Real se- They just exist and work somehow, that then get picked up by the relevant curity, not ‘we control the user’ aside from the occasional hard-to-de- maintainers. The break-in was two years security. code hiccup.” ago. Time to move on. nnn

94 June 2013 Issue 151 linux-magazine.com | Linuxpromagazine.com