On Mon, Aug 22, 2016 at 9:18 PM, Jarod Wilson <jarod@xxxxxxxxxx> wrote: > On Mon, Aug 22, 2016 at 08:34:02PM -0400, Josh Boyer wrote: >> On Mon, Aug 22, 2016 at 8:22 PM, Jarod Wilson <jarod@xxxxxxxxxx> wrote: >> > On Mon, Aug 22, 2016 at 03:50:22PM -0600, Chris Murphy wrote: >> >> On Mon, Aug 22, 2016 at 3:14 PM, Laura Abbott <labbott@xxxxxxxxxx> wrote: >> >> > On 08/22/2016 01:16 PM, Chris Murphy wrote: >> >> >> >> >> >> On Mon, Aug 22, 2016 at 2:08 PM, John Dulaney <jdulaney@xxxxxxx> wrote: >> >> >>> >> >> >>> On Mon, Aug 22, 2016 at 12:28:18PM -0700, Laura Abbott wrote: >> >> >>>> >> >> >>>> The secure boot patches have been around in the Fedora tree for a while >> >> >>>> now. >> >> >>>> They work well enough but there has not been much active work in getting >> >> >>>> them accepted upstream in recent years. The longer they exist out of >> >> >>>> tree >> >> >>>> the harder they get to maintain without extra support. If there isn't a >> >> >>>> path for the current secure boot patch set to be accepted upstream, we >> >> >>>> need >> >> >>>> to seriously consider if it's worth carrying long term. >> >> >>>> >> >> >>>> Thoughts? >> >> >>> >> >> >>> >> >> >>> So, how would we handle secure boot moving forward? >> >> >> >> >> >> >> >> >> How are other distros handling this? Does upstream have an alternative? >> >> >> >> >> > >> >> > There isn't one unified answer. Every distro seems to be doing something >> >> > different because upstream hasn't provided a single solution. >> >> > >> >> > Moving forward, we would treat secure boot like feature that is still >> >> > in progress. This means taking the existing secure boot patches or >> >> > a new approach and submitting them in a way that's acceptable to the >> >> > upstream >> >> > community. This is also code for "I don't know but what we have isn't >> >> > sustainable so let's discuss something better". >> >> >> >> Of course. >> >> >> >> What patch set are Red Hat and CentOS using? If they're not all using >> >> the same thing is it viable to get them all using the same thing? >> > >> > They're using the same basic thing, but CentOS 7 and it's grandfather are >> > based on a 3.10 kernel, so there's a gulf of difference in the codebase of >> > that and current Fedora kernels, meaning there's no way they're going to >> > be using exactly the same code. And once it works one particular way in >> >> Right. Functionally they're fairly similar but even from a Kconfig >> option standpoint they differ. >> >> > Red Hat Enterprise Linux, it's unlikely to be swapped out wholesale for >> > the "new and improved" upstream way until the next major RHEL release. >> > Enterprise stability and stuff. So yeah, no, you really can't get them all >> > using the same thing. The kernel codebases are just faaaar too different >> > for a fairly invasive patchset that touches bits and pieces all over the >> > place in core areas. >> >> The problem here is that there is no "new and improved" upstream >> stuff. Fedora has a patchset that has limped along and been very >> slightly tweaked with every rebase. So really, there's no upstream >> (in the kernel.org sense) stuff at all and that's the problem. > > Yeah, that's definitely the biggest problem here. > >> (BTW, aside from the key code, I would imagine most of the SB patchset >> actually could apply to an older kernel without much difficulty. It >> patches paths that don't really change all that much.) > > Ah, I may have been mixing it up with another set, or just plain making > bad assumptions about the complexity. I definitely had our old DSA module > signing code that we are still carrying in RHEL6 vs. the RSA module > signing code that finally went upstream in mind... I suppose it wouldn't I think you're remembering the GPG signing that RHEL6 had. RHEL7, Fedora, and upstream don't use GPG signing at all. They use certs and slap them at the end. That drastically simplifies some of the module loading code, but it makes a lot of packaging bits uglier. > patches. But yeah. Seems we (Red Hat) really ought to dedicate some > resources towards getting something accepted upstream so we don't have to > carry this around for eternity. 100% agreed. josh _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/kernel@xxxxxxxxxxxxxxxxxxxxxxx
