Various efforts always are underway to implement Secure
Boot and to
add features that will allow vendors to lock users out of controlling their
own systems. In that scenario, users would look helplessly on while their
systems refused to boot any kernels but those controlled by the vendors.
The vendors' motivation is clear—if they control the kernel, they can
then stream media on that computer without risking copyright infringement by
the user. If the vendor doesn't control the system, the user might
always have some secret piece of software ready to catch and store any
streamed media that could then be shared with others who would not pay the
media company for the privilege.
Recently, Chen Yu and other developers tried to submit patches to enhance
Secure Boot so that when the user hibernated the system, the kernel itself
would encrypt its running image. This would appear to be completely
unnecessary, since as Pavel Machek pointed out, there is
(userspace software suspend), which encrypts the running image before suspending
the system. As Pavel said, the only difference was that uswusp ran in userspace and not kernel space.
Perhaps in an effort to draw Chen into admitting the deeper motives behind
the patch submission, Pavel asked Chen to elucidate exactly what security
hole his patches addressed and how they would deal with them. Pavel would
ask that question over and over again before the end of the discussion, and
he would not receive an answer.
Chen offered a variety of justifications for the patch, including letting
users do less work, but none of them answered the fundamental question:
why was this patch needed as a security enhancement in the first place? And
eventually, Pavel called it like he saw it. He said, "Purpose here is to
prevent the user from reading/modifying kernel memory content on machine he
owns. Strange as it may sound, that is what 'secure' boot requires (and what
The discussion ended inconclusively, but not utterly. It's clear that Pavel,
and a group of core kernel developers including Linus
continue to guard against allowing vendors to control user systems.
This seems to be one of the fundamental values of the Linux kernel—to
prevent the reemergence of the kind of situation we had in the 1980s, where
vendors had ultimate control over virtually all software, while users were
at the mercy of business decisions they didn't agree with but could do
Note: if you're mentioned above and want to post a response above the comment section, send a message with your response text to email@example.com.