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?
Laura
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?
John.
On Mon, Aug 22, 2016 at 2:08 PM, John Dulaney jdulaney@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?
On 08/22/2016 01:16 PM, Chris Murphy wrote:
On Mon, Aug 22, 2016 at 2:08 PM, John Dulaney jdulaney@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".
Thanks, Laura
On Mon, Aug 22, 2016 at 3:14 PM, Laura Abbott labbott@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@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?
I'd think that without an upstream solution that this must be an issue for all the distros supporting Secure Boot in one form or another. Hmm, no schedule yet for Linux Kernel Summit and Linux Plumbers Conference.
Without Secure Boot we run up against making dual boot with Windows messier for users, effectively encouraging them to permanently leave it off which possibly opens them up to bootloader malware with their Windows installation. Most users will not flip Secure Boot enabled/disabled when going between Fedora and Windows, they'll just give up and leave it disabled, in my estimation. (I sorta hate dual boot, but that's beside the point.)
Disregarding the dual boot case, is some form of measured boot a better way forward? I have no idea what the state of hardware is with TPM vs Secure Boot.
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@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@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 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.
On Mon, Aug 22, 2016 at 8:22 PM, Jarod Wilson jarod@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@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@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.
(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.)
josh
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@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@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@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 actually be THAT hard to backport the RSA module signing code either, but we shipped DSA first, so... We're stuck with it. Fortunately, upstream acceptance of the RSA bits, we shipped that in 7, no more out of tree 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.
On Mon, Aug 22, 2016 at 9:18 PM, Jarod Wilson jarod@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@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@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@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.
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
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@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@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@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@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...
On Mon, Aug 22, 2016 at 6:34 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
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.
OK so Fedora's kernels, being substantially like upstream source, is in some sense disproportionately hit with this tweaking process, compared to other distros who tend to run older kernels. So maybe they have more time to make the necessary adaptations, where Fedora the tweaks are more urgent because, well from what I can see you've got sometimes a dozen hours after a mainline rc is released before there's a kernel build of it.
On 08/22/2016 05:22 PM, Jarod Wilson 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@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@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 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.
You're right, distros aren't going to swap out what they have in existing releases for the new hotness. I'd like to believe that if there was a workable upstream solution many distros would choose to converge on that for a future release with a corresponding kernel version. Maybe we will have to maintain some version of these patches for older kernels like Cent OS but newer kernels could be common.
Thanks, Laura
On Mon, Aug 22, 2016 at 06:00:44PM -0700, Laura Abbott wrote:
On 08/22/2016 05:22 PM, Jarod Wilson 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@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@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 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.
You're right, distros aren't going to swap out what they have in existing releases for the new hotness. I'd like to believe that if there was a workable upstream solution many distros would choose to converge on that for a future release with a corresponding kernel version.
Oh, they absolutely would, for future (major) releases. The issue is more that yes, we can do something new and different in Fedora, but not in CentOS/RHEL 7 or earlier.
Maybe we will have to maintain some version of these patches for older kernels like Cent OS but newer kernels could be common.
"We" being who? Red Hat is absolutely going to have to maintain them for RHEL, as it's already shipped as a supported feature, and will have to remain such for the life of at least RHEL7. CentOS gets it for free. Fedora really only has to be concerned with Fedora, though at some point, that could also carry over to the next RHEL kernel too... But if Red Hat really wants to ship something in the next RHEL kernel, maybe Red Hat ought to dedicate some resources to getting something upstream so we're not having to carry out-of-tree crud for both Fedora *and* RHEL...
> 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 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.
You're right, distros aren't going to swap out what they have in existing releases for the new hotness. I'd like to believe that if there was a workable upstream solution many distros would choose to converge on that for a future release with a corresponding kernel version. Maybe we will have to maintain some version of these patches for older kernels like Cent OS but newer kernels could be common.
Sounds like a good topic to be bought up at plumbers conf.
P
On Tue, Aug 23, 2016 at 4:05 AM, Peter Robinson pbrobinson@gmail.com 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 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.
You're right, distros aren't going to swap out what they have in existing releases for the new hotness. I'd like to believe that if there was a workable upstream solution many distros would choose to converge on that for a future release with a corresponding kernel version. Maybe we will have to maintain some version of these patches for older kernels like Cent OS but newer kernels could be common.
Sounds like a good topic to be bought up at plumbers conf.
The problem is, it was. Like 3 years ago. We even had agreement. Then things failed.
I'll be there and I'm happy to discuss it again, but I'm not holding my breath.
josh
On 08/22/2016 02:50 PM, Chris Murphy wrote:
On Mon, Aug 22, 2016 at 3:14 PM, Laura Abbott labbott@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@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?
I'd think that without an upstream solution that this must be an issue for all the distros supporting Secure Boot in one form or another. Hmm, no schedule yet for Linux Kernel Summit and Linux Plumbers Conference.
Without Secure Boot we run up against making dual boot with Windows messier for users, effectively encouraging them to permanently leave it off which possibly opens them up to bootloader malware with their Windows installation. Most users will not flip Secure Boot enabled/disabled when going between Fedora and Windows, they'll just give up and leave it disabled, in my estimation. (I sorta hate dual boot, but that's beside the point.)
Right. Secure boot _is_ an important feature.
Disregarding the dual boot case, is some form of measured boot a better way forward? I have no idea what the state of hardware is with TPM vs Secure Boot.
There is a TPM microconference happening at Plumbers (I think?).
Thanks, Laura
On Mon, Aug 22, 2016 at 7:17 PM, Laura Abbott labbott@redhat.com wrote:
On 08/22/2016 02:50 PM, Chris Murphy wrote:
On Mon, Aug 22, 2016 at 3:14 PM, Laura Abbott labbott@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@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?
I'd think that without an upstream solution that this must be an issue for all the distros supporting Secure Boot in one form or another. Hmm, no schedule yet for Linux Kernel Summit and Linux Plumbers Conference.
Without Secure Boot we run up against making dual boot with Windows messier for users, effectively encouraging them to permanently leave it off which possibly opens them up to bootloader malware with their Windows installation. Most users will not flip Secure Boot enabled/disabled when going between Fedora and Windows, they'll just give up and leave it disabled, in my estimation. (I sorta hate dual boot, but that's beside the point.)
Right. Secure boot _is_ an important feature.
Secure Boot is an important feature, I continuously question whether dual boot really is; but for now I accept it needs to be fairly bullet proof. And therefore Secure Boot needs to be supported, even if there were a fully acceptable substitute.
I guess with measured boot, whatever runtime services are available after ExitBootServices() maybe could still be compromised, which ostensibly should not be true with Secure Boot? *shrug* so maybe they're still different things with some overlap (policy wise anyway).
Disregarding the dual boot case, is some form of measured boot a better way forward? I have no idea what the state of hardware is with TPM vs Secure Boot.
There is a TPM microconference happening at Plumbers (I think?).
Dunno, I haven't seen the preliminary stuff and there's no schedule up for summit or plumbers still.
On 22.08.2016 23:14, Laura Abbott wrote:
On 08/22/2016 01:16 PM, Chris Murphy wrote:
On Mon, Aug 22, 2016 at 2:08 PM, John Dulaney jdulaney@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.
Hmmm. Is that really a good description of the current situation in this context? What patches are we actually talking about? I see about ten in git that are related to secure boot; among them are these:
http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/Add-option-to-automa... http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/Add-secure_modules-c... http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/efi-Disable-secure-b... http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/Add-sysrq-option-to-...
Those or similar patches are are in the latest ubuntu kernels as well:
http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=2c025dacea2... http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=b2d26ece193... http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=0838c26a636... http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=be77004bd69...
A few others are there as well afaics (I did not check for each and everyone). Ohh, and I can spot a few secure boot patches we use in in the SLE-SP2 kernel as well (hint: they are in the patches.suse tarball). And as stated already elsewhere in this thread the patches in RHEL have a connection to our patches as well.
So wouldn't it help already to look deeper into this and create a proper upstream for developing and upstreaming the patches some of the big players in the Distro market want and already use in some form?
Cu, knurd
On Tue, Aug 23, 2016 at 7:23 AM, Thorsten Leemhuis fedora@leemhuis.info wrote:
On 22.08.2016 23:14, Laura Abbott wrote:
On 08/22/2016 01:16 PM, Chris Murphy wrote:
On Mon, Aug 22, 2016 at 2:08 PM, John Dulaney jdulaney@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.
Hmmm. Is that really a good description of the current situation in this context? What patches are we actually talking about? I see about ten in git that are related to secure boot; among them are these:
http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/Add-option-to-automa... http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/Add-secure_modules-c... http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/efi-Disable-secure-b... http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/Add-sysrq-option-to-...
There are more.
Those or similar patches are are in the latest ubuntu kernels as well:
http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=2c025dacea2... http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=b2d26ece193... http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=0838c26a636... http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=be77004bd69...
A few others are there as well afaics (I did not check for each and everyone). Ohh, and I can spot a few secure boot patches we use in in the SLE-SP2 kernel as well (hint: they are in the patches.suse tarball). And as stated already elsewhere in this thread the patches in RHEL have a connection to our patches as well.
So wouldn't it help already to look deeper into this and create a proper upstream for developing and upstreaming the patches some of the big players in the Distro market want and already use in some form?
That was already done once. The problem isn't distro adoption. The problem is that despite being told we needed distro adoption (which we have) and despite coming to an agreement on upstreaming them, they continued to be nacked by other upstream developers that dislike them because they don't solve every possible threat model or they don't like the implementation. The latter can be changed, but when a lot of the argumentation is against SB on political grounds it tends to lead to developers chasing their tails.
I'm not opposed to revisiting this upstream at all, but I don't want people to get them impression that it will be simple or trivial to upstream.
josh
On 23.08.2016 13:32, Josh Boyer wrote:
On Tue, Aug 23, 2016 at 7:23 AM, Thorsten Leemhuis fedora@leemhuis.info wrote:
On 22.08.2016 23:14, Laura Abbott wrote:
Hmmm. Is that really a good description of the current situation in this context? What patches are we actually talking about? I see about ten in git that are related to secure boot; among them are these: http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/Add-option-to-automa... http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/Add-secure_modules-c... http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/efi-Disable-secure-b... http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/Add-sysrq-option-to-...
There are more.
Yeah, I know; guess you missed the "[…] see about ten […]" above. Whatever, that's not why I'm writing this mail.
That was already done once.
Yeah, but back then Ubuntu wasn't on board iirc, as they afaics added some of those patches only a few months ago. When 15.10 was released you could still load unsigned modules even when secure boot was enabled; that changed with a kernel update (I was told) and was different in 16.04 from the start.
IOW: one more and important player in the field with similar goals. I guess that was one of the points I wanted to make but didn't state clearly enough.
[…] I don't want people to get them impression that it will be simple or trivial to upstream.
+1
Cu, knurd
On Tue, Aug 23, 2016 at 6:57 AM, Thorsten Leemhuis fedora@leemhuis.info wrote:
On 23.08.2016 13:32, Josh Boyer wrote:
That was already done once.
Yeah, but back then Ubuntu wasn't on board iirc, as they afaics added some of those patches only a few months ago. When 15.10 was released you could still load unsigned modules even when secure boot was enabled; that changed with a kernel update (I was told) and was different in 16.04 from the start.
IOW: one more and important player in the field with similar goals. I guess that was one of the points I wanted to make but didn't state clearly enough.
Unfortunately, I don't recall Ubuntu developers being part of the upstream opposition that blocked this after agreement.
[…] I don't want people to get them impression that it will be simple or trivial to upstream.
+1
In theory, it should be, but we have seen that this isn't the case.
Justin
On 08/23/2016 11:32 AM, Josh Boyer wrote:
That was already done once. The problem isn't distro adoption. The problem is that despite being told we needed distro adoption (which we have) and despite coming to an agreement on upstreaming them, they continued to be nacked by other upstream developers that dislike them because they don't solve every possible threat model or they don't like the implementation.
If it was one of the usual upstream nackers like EWB then simply have those or him come up with the solution to the problem. If he or they cant ( or are dumb enough to think they can cover/secure every use case out there which is like chasing the rainbow, fighting war on drugs et basically mission impossible ) then obviously he or they have to accept this until something better comes along ( from themselves or someone else ) or he or they nack this again and distribution ( In this particular case Red Hat since it's maintaining the kernel in Fedora is a paid job not community one ) will be forced to make a choice of committing resources to maintain this indefinitely or drop this altogether.
JBG
On 08/22/2016 07:28 PM, 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?
Once you have figured out what's preventing it from being accepted upstream you figure out the way forward for downstream.
JBG
kernel@lists.fedoraproject.org
-
Chris Murphy -
Jarod Wilson -
John Dulaney -
Josh Boyer -
Justin Forbes -
Jóhann B. Guðmundsson -
Laura Abbott -
Peter Robinson -
Thorsten Leemhuis