On 2/21/2019 2:25 PM, Patrick Venture wrote:
> The ASPEED AST2400, and AST2500 in some configurations include a
> PCI-to-AHB MMIO bridge. This bridge allows a server to read and write
> in the BMC's memory space. This feature is especially useful when using
> this bridge to send large files to the BMC.
>
> The host may use this to send down a firmware image by staging data at a
> specific memory address, and in a coordinated effort with the BMC's
> software stack and kernel, transmit the bytes.
>
> This driver enables the BMC to unlock the PCI bridge on demand, and
> configure it via ioctl to allow the host to write bytes to an agreed
> upon location. In the primary use-case, the region to use is known
> apriori on the BMC, and the host requests this information. Once this
> request is received, the BMC's software stack will enable the bridge and
> the region and then using some software flow control (possibly via IPMI
> packets), copy the bytes down. Once the process is complete, the BMC
> will disable the bridge and unset any region involved.
>
> The default behavior of this bridge when present is: enabled and all
> regions marked read-write. This driver will fix the regions to be
> read-only and then disable the bridge entirely.
A complete drive by review, so I could be completely off here (most
likely am), but have you considered using virtio and doing some sort of
rudimentary features (regions here) negotiation over that interface?
If I get your description right in premise maybe emulating the AHB side
on the BMC as a PCI end-point device driver, and using it as a seemingly
regular PCI EP from the host side with BARs and stuff might make sense
here and be less of a security hole than it currently looks like.
--
Florian
