On Wed, May 26, 2021 at 01:59:57PM -0500, Joseph Reynolds wrote:
> On 5/26/21 8:43 AM, Joseph Reynolds wrote:
 
> > 1. Followup from last meeting re uboot, kexec, sysrq-trigger on ARM 
> > architecture.
> We re-hashed the discussion, added new information, and added new concerns.

Could you paste the minutes here when you reply to these?  It is kind of
hard to have any discussion with the rest of the community when you have
2-3 levels of indirection to get at the words.

> We think there are cultural differences between Linux and open source
> with respect to how we handle security items (but we didn't get into any
> details).

It is really hard to know what this is referring to or means or how it
might impact us.  There is no such thing as "open source" as something
different and separate from "Linux".  Certainly many sub-communities
within the OSS world have different priorities and approaches when it
comes to security.  This sounds like it was just idle chatter.

> Kernel's modules expect BMC hardware to be in a particular state. Kernel
> kexec’ing might lead to undefined behavior for such modules.

I think we're just talking about normal bugs here.  Those would be
caught and fixed in testing, wouldn't they?

> Worried about interactions with secure boot.
> Scenario: kernel 1 boots, then the BMC gets compromised, then kernel 2
> is kexec’d.

What is the "worry" here?  This isn't an unsolved problem as servers
have to deal with this all the time.

This is why secureboot itself isn't really all that useful without
attestation.  There are going to be compromised images.  You put them in
a block list.  When you kexec, since you haven't gone through a reset,
the TPM still contains the measurements from the compromised / blocked
image (which have now been extende with the kexec measurements as well).
So any system running code that is in your block list is still blocked
because you can't trust that it wasn't compromised.

> Kexec does not significantly improve the boot time of BMC.

And?  Was someone suggesting it would?  Not sure the context.

It seems like whoever is involved in these discussions is missing the
purpose of enabling kexec.  I don't think anyone is talking about using
kexec as a way to make some minor improvement in a once-in-a-while
OpenBMC upgrade + reboot path.

Kexec is being talked about because it is *the way you get kernel debug*
now.  Kdump requires kexec.  When the kernel crashes, you kexec to the
kdump kernel, it garthers a bunch of data, hopefully stores it in flash,
and then you can do a proper reboot back to your buggy-crashing kernel.

-- 
Patrick Williams