Re: MCTP over PCI on AST2500

From: "Andrew Jeffery" <andrew@aj.id.au>
To: "Michael Richardson" <mcr@sandelman.ca>
Cc: "Sharad Khetan" <sharad.khetan@intel.com>,
	"Vijay Khemka" <vijaykhemka@fb.com>, rgrs <rgrs@protonmail.com>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Subject: Re: MCTP over PCI on AST2500
Date: Mon, 13 Jan 2020 10:08:09 +1030	[thread overview]
Message-ID: <b33a4247-e76d-46bb-9853-cf246f55d6bf@www.fastmail.com> (raw)
In-Reply-To: <27265.1578670688@localhost>

On Sat, 11 Jan 2020, at 02:08, Michael Richardson wrote:
> 
> Andrew Jeffery <andrew@aj.id.au> wrote: 
>     > 
> 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.

We have a slightly more detailed description here:

https://github.com/openbmc/openbmc/issues/3475

With respect to PCIe, disabling the P2A causes the host kernel to fail probing
the  AST DRM driver on kernels before 4.12 (from memory). This impacts
POWER more than other host architectures due to invalid accesses triggering
EEH.

With respect to LPC, the issue is largely that the bit in the LPC controller to
disable the iLPC2AHB bridge only disables write access, the host can still
continue to issues arbitrary reads of the BMC address space. To prevent
arbitrary reads the BMC must disable the entire SuperIO controller, which
knocks out the ability to configure UARTs, GPIOs, and the LPC mailbox
among other functionality. On some platforms disabling SuperIO is feasible
(POWER based), but others may require some of this functionality be
present.

> 
> I can see that doing this in uboot is the earliest possible;

It's actually possible to disable the backdoors before the first instruction is
run on the ARM core with the firmware strapping feature, but it's likely the
result becomes platform-specific and integrating the configuration
into the flash image can be a bit fiddly (you could implement it with  a
custom u-boot linker script).

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

See the discussion of the watchdog reset modes in the link above.

Cheers,

Andrew