MCTP over PCI on AST2500
andrew at aj.id.au
Fri Jan 10 16:05:46 AEDT 2020
On Fri, 10 Jan 2020, at 14:10, Michael Richardson wrote:
> Andrew Jeffery <andrew at aj.id.au> 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
> > 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
> > down.
> 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:
But to answer your questions, you should read the MCTP Base Specification
(DSP0236) and MCTP PCIe VDM Transport Binding Specification (DSP0238)
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
> 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