Andrew Jeffery <andrew@aj.id.au> wrote:
    > 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.

Thanks, that description was very useful... very good job here.

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

That's an interesting challenge.
If it can read, then it can read crypto-secrets (private keys and session keys).
Does the AST have any internal places which aren't visible externally?  
I can see how this feature was really useful to debugging BMC code :-)
I wish I could answer this question myself, but I haven't found a public spec
for the AST yet.  Is the NDA process difficult, I wonder.

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

Yes, I can see that seems like crippling functionality.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [