On Mon, Nov 05, 2012 at 09:19:46PM -0800, Eric W. Biederman wrote: > Matthew Garrett <mj...@srcf.ucam.org> writes: > > > On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote: > > > >> For automated installs you don't have to satisfy me. Feel free to > >> deliver a lousy solution to your users. Just don't use your arbitrary > >> design decisions to justify your kernel patches. > > > > My kernel patches are justified by genuine user requirements. > > Hogwash.
You keep using that word, which is unfortunate. > If windows is not present on a system linux can not be used to boot a > compromised version of windows without user knowledge because windows is > not present. Correct. > If windows is present on a system then to install linux a user must be > present and push buttons to get the system to boot off of install media. Incorrect. UEFI boot priorities can be set without physical user interaction. > If a user is present a user presence test may be used to prevent a > bootloader signed with Microsoft's key from booting linux without the > users consent, and thus prevent Linux from attacking windows users. Correct, but precludes the kind of automated installs that I know real people do. The keys a machine carries don't vary depending on whether it shipped with Windows or not, so it's not possible to differentiate between the "shipped with Windows" and "shipped without Windows" cases when determining security models. > Therefore preventing the revokation of a signature with Microsoft's > signature from your bootloader does not justify elaborate kernel > modifications to prevent the booting a compromised version of windows. That's a stretch. Bored now. You're adding nothing new to anyone's understanding of the problem, and I'm just saying the same thing I've been saying for months, so I don't see any purpose in discussing this with you further. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
