Security Working Group - Wednesday May 12 - results

[Joseph Reynolds]

On 5/12/21 7:25 PM, Andrew Jeffery wrote:
> Hi Joseph,
>
> It tends to be useful to Cc the developers doing the work. Posting to
> the list without Cc'ing relevant people leaves discovery of your
> discussion to chance, where as adding them on To: or Cc: does two
> things:
>
> 1. Raises the chance that they'll pay attention to your discussion
> 2. Removes the impression that you're intentionally talking past them
>
> Please try to engage the relevant people directly in the discussion by
> adding them in To: or Cc.

Andrew,

Good advice, thanks!  This was not my topic.  I was simply recording the 
conversation and did not have a chance to follow up.  I am glad it got 
your attention.  In general, it is hard to know who to contact.  Note 
that I am following up on this item privately through other channels.  
Finally, during the meeting, I encouraged attendees to make comments in 
the relevant gerrit review process.

- Joseph

>
> On Thu, 13 May 2021, at 03:48, Joseph Reynolds wrote:
>> On 5/11/21 8:59 PM, Joseph Reynolds wrote:
>>> This is a reminder of the OpenBMC Security Working Group meeting
>>> scheduled for this Wednesday May 12 at 10:00am PDT.
>>>
>>> We'll discuss the following items on the agenda
>>> <https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI/edit>,
>>> and anything else that comes up:
>>>
>> Three items were discussed.  You might want to start with item 3 first
>> to introduce the first two.  Summary:
>>
>> 1. Security impacts of enabling kexec (load and optionally execute new
>> kernel) in the BMC's production kernel.  How does this work and play
>> with secure boot and with IMA?
> Have you engaged with OpenBMC's kernel developers? They might be are
> interested in this problem. I'm vaguely aware of some work-in-progress
> patches that allows kexec to load FIT images, which can be signed and
> validated. This would mitigate execution of arbitrary kernels and also
> helps avoid the problem of shipping multiple kernel binaries or
> extracting artefacts from a FIT to pass to kexec.
>
>> 2. What are the security impacts of having the proc file system file
>> /proc/sysrq-triggerwhich can cause kernel panics which can cause the BMC
>> to terminate processing?
>>
>> 3. In general, how can you (an operator or the BMC's host system)
>> recover a BMC which has become unresponsive, for example, because its
>> kernel processing has failed.  A design introduces using
>> /proc/sysrq-triggertogether with a recovery kernel installed by kexec.
> To be clear, the use of /proc/sysrq-trigger is a temporary hack to
> reboot the BMC in the absence of kexec/kdump. Once those features are
> merged the application implementing this behaviour can invoke kexec
> directly. The slight advantage of /proc/sysrq-trigger is that with or
> without kexec/kdump enabled the BMC will reboot, and if kexec/kdump are
> enabled then it will automatically take advantage of them.
>
> In the specific case p10bmc platforms the host has access to a GPIO
> tied to the BMC's EXTRST line, so with or without this software feature
> the host can mount denial of service attacks of arbitrary length. This
> hardware design places the BMC and host firmware in the same trust
> domain.
>
> Andrew