MCTP over PCI on AST2500

[Michael Richardson]

Andrew Jeffery <andrew at aj.id.au> wrote:
    >> I have read through a few MCTP documents on dtmf.org, but they either dealt
    >> with too highlevel (SMBIOS tables), or too low-level (MCTP over UART).
    >>
    >> Is there something that I can read that explains the underlying PCI
    >> relationships between the BMC and the host CPU's PCI/bridges?
    >> Maybe I just need to read the AST2500 datasheet?

    > Beware that I brainfarted in my reply above, so before I go further:

    > https://lists.ozlabs.org/pipermail/openbmc/2020-January/020141.html

yes, I got that part :-)

    > But to answer your questions, you should read the MCTP Base Specification
    > (DSP0236)[1] and MCTP PCIe VDM Transport Binding Specification (DSP0238)[2]
    > and reference the MCTP Controller section of the ASPEED datasheets.

    > [1] https://www.dmtf.org/sites/default/files/standards/documents/DSP0236_1.3.0.pdf
    > [2] https://www.dmtf.org/sites/default/files/standards/documents/DSP0238_1.1.0.pdf

Thank you, this is what I was looking for.

    >> (I was at one point quite knowledgeable about PCI, having designed adapter
    >> cards with multiple targets and dealt with swizzling, and BARs, etc.)
    >>
    >> What I heard is that for typical AST2500 based BMCs, the host CPU can map the
    >> entire address space of the AST2500, and this rather concerns me.

    > Yes, this is indeed concerning. It has its own CVE:

    > https://nvd.nist.gov/vuln/detail/CVE-2019-6260

I was concerned that it really was this bad.

    > OpenBMC provides mitigations through the `phosphor-isolation` distro feature.
    > The feature enables this u-boot patch that disables all of the backdoors early in
    > u-boot:

    > https://github.com/openbmc/meta-phosphor/blob/master/aspeed-layer/recipes-bsp/u-boot/files/0001-aspeed-Disable-unnecessary-features.patch

    > The distro feature is opt-in as it has impacts beyond simply disabling the backdoors
    > (there are some unfortunate side-effects to enforcing confidentiality of the BMC's
    > address space.

okay, so the bridge gets turned off, and it has some other effects.
What are the side effects?  I'm guessing by the inclusion of the VGA defines
in that board init that they are video related.

I can see that doing this in uboot is the earliest possible; but in most
cases the main CPU has no power until the BMC boots, so it can't attack until
the BMC is running.  Are there some situations in which the BMC (or the P2A
bridge) could get reset without the host CPU also being reset?

    >> I had rather expected some kind of mailbox system in a specialized ram that
    >> both systems could use to exchange data.

    > Well, a few of us at IBM have cooked up an LPC binding that is not yet standardised
    > but does exactly this. We use a KCS device to send byte-sized control commands
    > and interrupts between the host and the BMC, and use a reserved memory region
    > mapped to the LPC firmware space to transfer message data. I don't think we've
    > published the spec yet, but I can put the work in to get it onto the list.

That's cool, I'm glad that you've gone this way.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200110/b4da1d2d/attachment.sig>