On Tue, Aug 23, 2016 at 06:47:27AM -0400, Josh Boyer wrote: > 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. Nope, definitely thinking DSA vs. RSA -- I had to wrestle with figuring out how to actually test the non-upstream DSA modsigning implementation for FIPS certification back in RHEL5 and RHEL6, and was quite happy when we didn't have to do that any longer in RHEL7. :) But GPG sigs were a pain as well. > > 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. I'm guessing nobody ever really picked up this ball and ran with it after mjg left Red Hat... -- Jarod Wilson jarod@xxxxxxxxxx _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/kernel@xxxxxxxxxxxxxxxxxxxxxxx
