Security Working Group - Wednesday May 26 - results

Joseph Reynolds jrey at
Fri May 28 01:04:12 AEST 2021

On 5/27/21 7:56 AM, Patrick Williams wrote:
> 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.

Thanks for your email!

Yes, I've waffled between cut/paste of the minutes and summarizing 
them.  I prefer to cut/paste, so I'll do that consistently from now on.

>> 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.

I wasn't sure what this meant when it was said.  It believe it refers to 
my floundering interactions with
Nobody at the meeting followed up on that statement. I've since address 
the comment in the review.

>> 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.

The worry is that security boot is not a complete solution, as you 
pointed out.

>> 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.

I get the same feeling.  Using kexec was brought up in the context of 
kernel debug, and the conversation wandered off. :-(

- Joseph

More information about the openbmc mailing list