Re: In-Band Firmware Update

[Vernon Mauery <vernon.mauery@linux.intel.com>]

On 08-Aug-2018 09:32 AM, Jeremy Kerr wrote:
>Hi Ed,
>
>>>We are going to investigate using the DFU protocol, as that
>>>also has host side tools already available.
>>
>>DFU doesn't completely solve the issue though, does it?  Presumably 
>>for security reasons you can't have the DFU device exposed to the 
>>host all the time.  If you did, I'm sure the penetration testers 
>>would hit it hard.  Assuming that leaving it available all the time 
>>is a non-starter, don't you need some command to activate the 
>>interface to allow the upload?
>
>Yes, we'd have an endpoint exposed all the time (the run-time descriptor
>set). This changes into the DFU mode descriptor set at the start of the
>upgrade process, when the host-side tools issue a DFU_DETACH.
>
>Does hiding the descriptor get us anything, if it can be enabled from
>the host anyway? The run-time descriptor is super simple.

I am not saying security by obscurity is good, but there is a difference 
between an unlocked door and an open one. I am sure our security team 
would not want the firmware update descriptor present at all times.

>>Assuming I'm not missing something there (I probably am) doesn't it 
>>make more sense to just expose a USB mass storage device when the 
>>"start" command is sent, as opposed to implementing the full DFU 
>>protocol?  It seems like that would require no utilities (aside from 
>>a simple nsh/bash script) and be very easy to replicate.
>
>Just that this requires more custom stuff host-side; raw IPMI commands
>for the start and stop (unless we can hook into a SCSI eject event for
>the stop perhaps). If we can use existing tools that already support
>DFU, that's less stuff that needs to be provided on the host side.
>
>That said, it does look like the current DFU spec isn't going to allow
>fast enough transfers for a BMC firmware image in reasonable times, so
>we may have to modify those *anyway*, so most of the benefit there may
>be lost...

Speed is a big thing. With firmware image sizes as big as they are, we 
cannot afford slow transfers.

>A USB-mass-storage-based solution could be okay, as long as we have a
>solid specification for what gets written to the device (a filesystem
>containing the image? raw image on the device?), secure parsing for that
>data (particularly if the BMC is reading a filesystem) and a protocol
>between BMC and host so that we can implement proper handover. If we can
>use standard tools for that, it might be a good way to go.

If the BMC exports an empty FAT filesystem, just about anything can read 
that. It is easy to parse on the inbound and can easily be done with a 
loop-mount. In this case though, it would be nice to have some sort of 
control that tells the BMC when to "plug in" and "eject" the device 
to/from the host for synchronization mechanisms. The BMC could then look 
at the volume and attempt to use each file as a firmware volume to 
prepare for activation.

--Vernon