On Mon, Aug 22, 2016 at 9:18 PM, Jarod Wilson
<jarod(a)redhat.com> 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(a)redhat.com> 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(a)redhat.com> wrote:
>> >> > On 08/22/2016 01:16 PM, Chris Murphy wrote:
>> >> >>
>> >> >> On Mon, Aug 22, 2016 at 2:08 PM, John Dulaney
<jdulaney(a)gnu.org> 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(a)redhat.com