It'll only boot grub if grub is signed with a key that a physically present user has manually enrolled. If you choose to enrol a key that's been used to sign a grub that'll then boot anything (including viruses) then you're vulnerable, but such a virus would only be able to infect systems with that key installed - anyone who hasn't installed that key still gets the protection.
Given that I've been working with the Microsoft people who manage the signing for the best part of a year now, I'm pretty sure they know who I am and what I was getting signed.
If your system currently has Windows 8 installed, then do this:
1) Insert the install media 2) Mouse to the bottom right 3) Select "Settings" 4) Click "Power" 5) While holding down shift, click "Restart" 6) Click "Use a device" 7) Click your install media
This is a little more involved than ideal, but it's got the huge benefit that it's consistent between systems rather than requiring you to use different hotkeys for different platforms.
As the author of the linked article, things have somewhat changed since then - the language in the hwcert docs makes it clear that the hardware can be configured into a state where keys can be added. Is it a guarantee? No, but it's as close as is possible to get in the technology world.
"Right and if the modifications have absolutely nothing to do with the kernel or drivers then there is no obligation."
No. You must provide either the source or a written offer to provide the source to any third party on request regardless of whether you've modified the GPLed material or not.
No. If you distribute under 3(b), then as long as I'm not distributing commercially I can distribute under 3(c) and pass on the written offer - which still leaves you responsible for providing the source.
Yes, but given that the kernel is under GPLv2 (not v2 or later), what GPLv3 says isn't terribly relevant...
Even then, the written offer must be good for anyone who obtains the object code. I download a firmware image from your site? You're obliged to give me source on request. One of your customers downloads a firmware image and then gives it to me? The same applies.There's no point at which it's limited to your customers.
And by "drivers" here, I also mean "board setup code". I can guarantee you that the MSM code in the Google tree isn't going to know which gpio lines are connected to your tablet's LCD power control, even if the CPU happens to be the same one that was in the G1.
"Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange"
You don't have to choose that option - you can use 3(a) instead, but that means that the source has to be with the device when you sell it.
The Google reference kernel code doesn't contain the driver code for any of these tablets, and the vast majority of them are based on SoC platforms that don't exist at all in the Google code. The tablet vendors can't simply point at the Google repositories, they're obliged to either ship the source with the devices or provide a written offer to provide the source to any third party on request.
Firstly, thanks for posting this. It's the kind of thing that we never really got out of previous discussion on the topic, which makes it much harder to make reasonable technical decisions.
Secondly, your results are interesting. I'd be fascinated to know whether they're due to the implicit differences between retention and suspend (ie, transitioning to full suspend stops processes that would otherwise be generating wakeups while retention doesn't, or cuts power planes that should otherwise be powered down manually) or because of fundamental silicon level issues. On the other hand, I don't think it fundamentally matters. We have an rtc that's capable of generating wakeup events, so it's acceptable for the lowest level runtime idle state to be system suspend with the rtc set for the next scheduler tick. Just make sure that the latency values are set correctly and it ought to work fine with the existing cpuidle code.
Android is written to automatically attempt to enter a sleep state whenever possible. So, for instance, when your phone is in your pocket the hardware is suspended. You get an incoming call. You pick up a phone and press a button. The button press fully wakes up the phone. What stops the phone from suspending again? Wakelocks are Google's solution to this. Pressing the button takes a named wakelock. While any wakelocks are held, the phone will not go back to sleep. Once the call is complete, userspace can release the wakelock and the phone will suspend again.
The problem here is that your wakelocks are tied to your userspace. Userspace needs to know which wakelocks the kernel takes in order to be able to release them. Which wakelocks you want will depend on how your platform is designed. Google have implemented the wakelocks they need to solve the problems they face - other vendors may wish to use different wakelocks. The end result is that you end up with a kernel that can only usefully run with a specific userland, and userland modifications require kernel modifications. It's broadly like saying that it'd be fine for some kernel drivers to require gnome and some others to require KDE.
What's depressing about this is that it's an entirely unnecessary approach. You don't need the system to fully suspend. Modern ARM hardware supports something generally referred to as retention mode, which is where the hardware enters a power state equivalent to suspend without actually performing a full state transition. Rather than explicitly suspending, if there are no tasks to run then the kernel idle routine will put the CPU into this state. When a task is scheduled to run (either because of a timer or in response to an event), it runs.
The stated objection to this is that applications can't be trusted to behave themselves. If I write an Android application that repaints itself by sleeping for a frame and then drawing, that'll keep waking up the CPU. In the wakelock scenario, the system isn't running and so this isn't a problem. In the retention scenario, it'll keep getting scheduled and battery life will suffer.
There's two easy solutions to this. The first is to use the range timer functionality in the kernel. This allows applications to say "I want to sleep for about a second, and can afford this much inaccuracy". The kernel uses this to attempt to merge wakeups - if an application sleeps for a second and a millisecond later another application does the same, they can both be woken up at once rather than causing two wakeups. But we can also take this to more extreme lengths, for instance by changing the accuracy value to a millennium when the screen is turned off. The application won't get scheduled again until we receive a "wakeup" event and set the timers back. The second approach is even simpler - just SIGSTOP all non-system tasks when we'd otherwise release the wakelocks.
So I wouldn't frame this as refusing to meet Google halfway. People have tried to come up with solutions that would meet the usecases that Google want to deal with and which don't end up forcing people to tie their kernel to their userland. Nokia achieve comparable power consumption without any of the wakelock infrastructure, so it's clearly not a requirement in order to hit these targets. What would you expect a meeting halfway solution to look like?
Every Intel Mac I've seen locks down the SMRAM area in the firmware. There's no way to modify the SMM calls unless you can replace the firmware - and if you can do that, there are easier ways to take control of the machine (such as embedding malicious code in the ACPI tables)
The kernel simply doesn't make BIOS calls. It still does things that may cause BIOS code to be run, primarily in the form of hardware accesses that are trapped and cause system management interrupts.
Yes. The fact that the SMRAM is locked from the OS doesn't matter - it's still accessible when the CPU's in system management mode. Since (in the absence of ridiculous BIOS bugs) there's no way to get a CPU in SMM to execute arbitrary code or rewrite arbitrary sections of the SMRAM, this isn't an issue.
Slashdot Mirror
Well, that's the point. Nothing you run before reboot will be able to run in the firmware, because it doesn't have the right signature.
No, only the first time you install a given key.
It must be possible to install your own keys, but that may be implemented by allowing you to clear the platform key and switch back to setup mode.
It'll only boot grub if grub is signed with a key that a physically present user has manually enrolled. If you choose to enrol a key that's been used to sign a grub that'll then boot anything (including viruses) then you're vulnerable, but such a virus would only be able to infect systems with that key installed - anyone who hasn't installed that key still gets the protection.
Given that I've been working with the Microsoft people who manage the signing for the best part of a year now, I'm pretty sure they know who I am and what I was getting signed.
If your system currently has Windows 8 installed, then do this:
1) Insert the install media
2) Mouse to the bottom right
3) Select "Settings"
4) Click "Power"
5) While holding down shift, click "Restart"
6) Click "Use a device"
7) Click your install media
This is a little more involved than ideal, but it's got the huge benefit that it's consistent between systems rather than requiring you to use different hotkeys for different platforms.
"With a UEFI Secure Boot that requires a Microsoft signed key, how does one generate a self-signed key that works?"
openssl req -new -nodes x509 -outform DER -out sig.crt -keyout signing_key.priv
And then enrol it with mokutil or MokManager from shim.
Malware doesn't have a key in KEK, so it can't.
Keys can be revoked through OS updates. Check the UEFI spec for discussion of authenticated variables and dbx.
As the author of the linked article, things have somewhat changed since then - the language in the hwcert docs makes it clear that the hardware can be configured into a state where keys can be added. Is it a guarantee? No, but it's as close as is possible to get in the technology world.
"Right and if the modifications have absolutely nothing to do with the kernel or drivers then there is no obligation."
No. You must provide either the source or a written offer to provide the source to any third party on request regardless of whether you've modified the GPLed material or not.
Why do you think it makes any difference whether or not they modified it?
Yes. Your offer says "interested customers", whereas 3(b) says "any third party".
No. If you distribute under 3(b), then as long as I'm not distributing commercially I can distribute under 3(c) and pass on the written offer - which still leaves you responsible for providing the source.
"Must make it available ON REQUEST, to a person who received the binary."
I'd really recommend that you re-read 3(b) of GPLv2, which is what's relevant in this discussion.
Yes, but given that the kernel is under GPLv2 (not v2 or later), what GPLv3 says isn't terribly relevant...
Even then, the written offer must be good for anyone who obtains the object code. I download a firmware image from your site? You're obliged to give me source on request. One of your customers downloads a firmware image and then gives it to me? The same applies.There's no point at which it's limited to your customers.
And by "drivers" here, I also mean "board setup code". I can guarantee you that the MSM code in the Google tree isn't going to know which gpio lines are connected to your tablet's LCD power control, even if the CPU happens to be the same one that was in the G1.
Quoting from the GPL v2 section 3(b):
"Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange"
You don't have to choose that option - you can use 3(a) instead, but that means that the source has to be with the device when you sell it.
By Coby? Telechips released their reference kernel earlier this month, but I've seen no indication that Coby are fulfilling their obligations.
The Google reference kernel code doesn't contain the driver code for any of these tablets, and the vast majority of them are based on SoC platforms that don't exist at all in the Google code. The tablet vendors can't simply point at the Google repositories, they're obliged to either ship the source with the devices or provide a written offer to provide the source to any third party on request.
Firstly, thanks for posting this. It's the kind of thing that we never really got out of previous discussion on the topic, which makes it much harder to make reasonable technical decisions.
Secondly, your results are interesting. I'd be fascinated to know whether they're due to the implicit differences between retention and suspend (ie, transitioning to full suspend stops processes that would otherwise be generating wakeups while retention doesn't, or cuts power planes that should otherwise be powered down manually) or because of fundamental silicon level issues. On the other hand, I don't think it fundamentally matters. We have an rtc that's capable of generating wakeup events, so it's acceptable for the lowest level runtime idle state to be system suspend with the rtc set for the next scheduler tick. Just make sure that the latency values are set correctly and it ought to work fine with the existing cpuidle code.
Some background on this:
Android is written to automatically attempt to enter a sleep state whenever possible. So, for instance, when your phone is in your pocket the hardware is suspended. You get an incoming call. You pick up a phone and press a button. The button press fully wakes up the phone. What stops the phone from suspending again?
Wakelocks are Google's solution to this. Pressing the button takes a named wakelock. While any wakelocks are held, the phone will not go back to sleep. Once the call is complete, userspace can release the wakelock and the phone will suspend again.
The problem here is that your wakelocks are tied to your userspace. Userspace needs to know which wakelocks the kernel takes in order to be able to release them. Which wakelocks you want will depend on how your platform is designed. Google have implemented the wakelocks they need to solve the problems they face - other vendors may wish to use different wakelocks. The end result is that you end up with a kernel that can only usefully run with a specific userland, and userland modifications require kernel modifications. It's broadly like saying that it'd be fine for some kernel drivers to require gnome and some others to require KDE.
What's depressing about this is that it's an entirely unnecessary approach. You don't need the system to fully suspend. Modern ARM hardware supports something generally referred to as retention mode, which is where the hardware enters a power state equivalent to suspend without actually performing a full state transition. Rather than explicitly suspending, if there are no tasks to run then the kernel idle routine will put the CPU into this state. When a task is scheduled to run (either because of a timer or in response to an event), it runs.
The stated objection to this is that applications can't be trusted to behave themselves. If I write an Android application that repaints itself by sleeping for a frame and then drawing, that'll keep waking up the CPU. In the wakelock scenario, the system isn't running and so this isn't a problem. In the retention scenario, it'll keep getting scheduled and battery life will suffer.
There's two easy solutions to this. The first is to use the range timer functionality in the kernel. This allows applications to say "I want to sleep for about a second, and can afford this much inaccuracy". The kernel uses this to attempt to merge wakeups - if an application sleeps for a second and a millisecond later another application does the same, they can both be woken up at once rather than causing two wakeups. But we can also take this to more extreme lengths, for instance by changing the accuracy value to a millennium when the screen is turned off. The application won't get scheduled again until we receive a "wakeup" event and set the timers back. The second approach is even simpler - just SIGSTOP all non-system tasks when we'd otherwise release the wakelocks.
So I wouldn't frame this as refusing to meet Google halfway. People have tried to come up with solutions that would meet the usecases that Google want to deal with and which don't end up forcing people to tie their kernel to their userland. Nokia achieve comparable power consumption without any of the wakelock infrastructure, so it's clearly not a requirement in order to hit these targets. What would you expect a meeting halfway solution to look like?
Every Intel Mac I've seen locks down the SMRAM area in the firmware. There's no way to modify the SMM calls unless you can replace the firmware - and if you can do that, there are easier ways to take control of the machine (such as embedding malicious code in the ACPI tables)
The kernel simply doesn't make BIOS calls. It still does things that may cause BIOS code to be run, primarily in the form of hardware accesses that are trapped and cause system management interrupts.
Yes. The fact that the SMRAM is locked from the OS doesn't matter - it's still accessible when the CPU's in system management mode. Since (in the absence of ridiculous BIOS bugs) there's no way to get a CPU in SMM to execute arbitrary code or rewrite arbitrary sections of the SMRAM, this isn't an issue.