MCTP over PCI on AST2500

[Andrew Jeffery]

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

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

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

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.

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

Andrew