On Tue, Apr 3, 2018 at 7:56 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, Apr 3, 2018 at 5:46 PM, Matthew Garrett <mjg59@xxxxxxxxxx> wrote: >> >> The generic distros have been shipping this policy for the past 5 years. > > .. so apparently it doesn't actually break things? Why not enable it > by default then? > > And if "turn off secure boot" really is the accepted - and actuially > used - workaround for the breakage, then > While there is very little breakage in the *years* we have been shipping this in distro kernels, the accepted and used workaround has always been "turn off secure boot" or sign/import your own keys, depending on the problems encountered. > WHY THE HELL DIDN'T YOU START OFF BY EXPLAINING THAT IN THE FIRST > PLACE WHEN PEOPLE ASKED WHY THE TIE-IN EXISTED? > > Sorry for shouting, but really. We have a thread of just *how* many > email messages that asked for the explanation for this? All we got was > incomprehensible and illogical crap explanations. > > If there actually was a good explanation for the tie-in, it should > have been front-and-center and explained as such. > Honestly, yes, the major distros have been shipping this patch set for years now, and every time it comes to upstream, the same damn arguments emerge. I do not disagree that there are uses for lockdown outside of secure boot, provided you have some other mechanism to verify your chain, I believe chrome OS does. But the tie to secure boot is because that is the use case that users have been using for years, it was discussed at kernel summit quite a while ago, plans went forward there seemed to be agreement, and when it comes time for a pull request, people come out of the woodwork with an expectation that it solves every problem or it doesn't need to exist. What is here is a good starting point. I would expect that if it were merged, others would build upon that and use much of the code already in place to extend it. It is tied to secure boot because that is what has been using this for years as it never seems to get upstream. I am sure that once it does finally land, it can and will be extended to other things, but I don't think I would want to spend a lot of time trying to leverage another external patch set that has been delayed upstream so many times until it actually did land. As for the ties to MS that come up every time, and have here as well, there is no requirement on the MS signature. You can import your own keys if you don't want them involved, I keep a "test key" imported for actually running what I build locally. -- 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
