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(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.
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-aut...
http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/Add-secure_module...
http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/efi-Disable-secur...
http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/Add-sysrq-option-...
Those or similar patches are are in the latest ubuntu kernels as well:
http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=2c025dac...
http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=b2d26ece...
http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=0838c26a...
http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=be77004b...
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