MCTP over PCI on AST2500

Andrew Jeffery andrew at
Fri Jan 10 16:05:46 AEDT 2020

On Fri, 10 Jan 2020, at 14:10, Michael Richardson wrote:
> Andrew Jeffery <andrew at> wrote:
>     > On Sat, 21 Dec 2019, at 10:45, Khetan, Sharad wrote:
>     >> Hi Andrew,
>     >> Sorry for late response.
>     >> The plan is to have MCTP in user space.
>     >>
>     > How are you handling this then? mmap()'ing the BAR from sysfs?
>     > I plan to get back to implementing in-kernel socket-based MCTP 
> shortly.
>     > Unfortunately it slipped back a little in my priority list late 
> last year. I'd be
>     > interested in your feedback on the proposal when I get something 
> written
>     > down.
> I have read through a few MCTP documents on, 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:

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.


> (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:

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

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.

> 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.

Hope that helps,


More information about the openbmc mailing list