Earlier quoted context omitted.
Microsoft is in an impossible position here. Signed kernels are the only way to prevent rootkits. If they don't move in this direction people will complain about insecurity. If they do we get complaints about locking down the platform.
How about letting the owner uploading keys combined with a hardware switch to enable that?
In Defense of Free Software: My Case Against Lenovo in Mexico
31–33 of 33 posts
Re: In Defense of Free Software: My Case Against Lenovo in Mexico
#32Earlier quoted context omitted.
> loads GRUB As your link mentions, that loader only loads signed kernels (with signed modules). edit: > designed to prevent malware That's the official story. Anybody familiar with Microsoft's history knows they have been trying to lock down the wintel platform for a long time. Creating a "Trusted Computing" environment specifically for DRM purposes has been a goal since "Palladium".
I thought twice about responding to this. I worked on Palladium from very early days in 2002 through renaming to NGSCB and the eventual shutdown/transition of the project to ship BitLocker in Vista The team never saw DRM as being an interesting use case. Remember that the Darknet paper [1] was written by the Palladium architects and product manager. The team fully understood that DRM wasn't an effective use of a secu…
[1] http://www.bearcave.com/misl/misl_tech/msdrm/darknet.htm
Re: In Defense of Free Software: My Case Against Lenovo in Mexico
#33Earlier quoted context omitted.
Microsoft seems to have used a phased-in strategy: first it was all optional, then it should be there by default but ALSO with a mandatory option to disable to get the Windows logo (and probably goes with big OEM deals) then IIRC with Windows 10 MS dropped the mandatory removable part (but it is still ok to have it) on x86, and on non-x86 this is probably already mandatory to NOT be able to remove it. I guess in a fe…
How does Secure Boot enable malware to "hide in there more efficiently"? With or without Secure Boot, a compromised bootloader is in a privileged position, but not any more so with Secure Boot, from what I can tell.
This is for this reason that the security community consider the Intel Management Engine a huge security risk, and the situation is only marginally better with x86 firmware using such "security" features.