All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Richardson <mcr@sandelman.ca>
To: "Andrew Jeffery" <andrew@aj.id.au>
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 12:09:02 -0500	[thread overview]
Message-ID: <21526.1578935342@localhost> (raw)
In-Reply-To: <b33a4247-e76d-46bb-9853-cf246f55d6bf@www.fastmail.com>

[-- Attachment #1: Type: text/plain, Size: 2512 bytes --]


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    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

      reply	other threads:[~2020-01-13 17:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-20  5:26 MCTP over PCI on AST2500 rgrs
2019-11-20  6:54 ` Vijay Khemka
2019-11-20  6:59   ` Khetan, Sharad
2019-11-22  0:38     ` Andrew Jeffery
2019-12-21  0:15       ` Khetan, Sharad
2020-01-09  1:57         ` Andrew Jeffery
2020-01-09 18:17           ` Vijay Khemka
2020-01-09 20:45             ` Richard Hanley
2020-01-10  1:29               ` Andrew Jeffery
2020-01-10  0:30           ` Andrew Jeffery
2020-01-13 16:53             ` Khetan, Sharad
2020-01-13 18:54               ` Deepak Kodihalli
2020-01-14  5:54                 ` Khetan, Sharad
2020-01-14  6:20                   ` Jeremy Kerr
2020-01-14  6:39                     ` Khetan, Sharad
2020-01-14  8:10                       ` Deepak Kodihalli
2020-01-14 15:54                       ` Thomaiyar, Richard Marian
2020-01-14 17:45                     ` Patrick Williams
2020-01-15 13:51                       ` Jeremy Kerr
2020-01-15 14:16                         ` Patrick Williams
2020-01-14  8:54                   ` rgrs
2020-01-13 23:22               ` Andrew Jeffery
2020-01-10  3:40           ` Michael Richardson
2020-01-10  5:05             ` Andrew Jeffery
2020-01-10 15:38               ` Michael Richardson
2020-01-12 23:38                 ` Andrew Jeffery
2020-01-13 17:09                   ` Michael Richardson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=21526.1578935342@localhost \
    --to=mcr@sandelman.ca \
    --cc=andrew@aj.id.au \
    --cc=openbmc@lists.ozlabs.org \
    --cc=rgrs@protonmail.com \
    --cc=sharad.khetan@intel.com \
    --cc=vijaykhemka@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.