On Tue, Apr 3, 2018 at 4:08 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > That's not the right approach to begin with, Matthew. The onus is on > *you* to explain why you tied them together, not on others to explain > to you - over and over - that they have nothing to do with each other. 1) Secure Boot is intended to permit the construction of a boot chain that only runs ring 0 code that the user considers trustworthy 2) Allowing arbitrary user code to run in ring 0 without affirmative consent on the part of the user is therefore incompatible with the goals of Secure Boot 3) This patchset provides a mechanism to alter the behaviour of the kernel such that it is significantly more difficult for arbitrary user code to run in ring 0 without affirmative user consent 4) Providing a mechanism for automatically enabling this behaviour when running in a context that is intended to restrict access to ring 0 is a rational thing to do, because otherwise it is difficult to achieve the objective in (1) Alternative approaches to achieve (1) rely on severely constraining userland - ChromeOS, for instance, doesn't impose these restrictions at present but also doesn't allow users to run arbitrary applications (you're stuck inside either the Chrome or Android sandbox). So, if the goal is to achieve (1) when the platform is in this state, what's a more reasonable alternative? -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
