Security Working Group - Wednesday May 26 - results

[Joseph Reynolds]

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 
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/42948
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