[PATCH u-boot v2019.04-aspeed-openbmc] aspeed: add CONFIG_ASPEED_ISOLATE_BMC

Zev Weiss zev at bewilderbeest.net
Thu Apr 14 18:41:32 AEST 2022


On Thu, Apr 14, 2022 at 01:13:37AM PDT, Joel Stanley wrote:
>On Thu, 14 Apr 2022 at 04:05, Zev Weiss <zev at bewilderbeest.net> wrote:
>>
>> This provides the functionality of the OpenBMC df-isolate-bmc distro
>> feature flag, and is very directly derived from Andrew Jeffery's patch
>> in the OpenBMC tree for the v2016.07 u-boot branch.  The
>> implementation currently only supports ast2500, though ast2400 and
>> ast2600 support should be fairly simple extensions.
>>
>> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
>> ---
>>
>> This is meant more as something of an RFC to see if this seems like
>> approximately the right way of going about this (since as far as I can
>> see the existing df-isolate-bmc implementation only supports the old
>> 2016 u-boot branch), but if it looks OK I suppose it could potentially
>> go in as-is.
>
>Thanks for doing this. The only potential change I can suggest is we
>make each bit of hardware a different option (or we allow it to be
>configured in the device tree). That assumes someone has a use case
>for leaving one of the backdoorts open but closing the others.
>

This possibility came up on Discord with Andrew earlier -- I agree it'd 
be nice to have somewhat more fine-grained control over it, though I'm 
not aware of any platforms that really need it at the moment.  I'm 
certainly not as well-versed as Andrew in the precise details of exactly 
how all the various busses interact in different circumstances (this was 
just a fairly mechanical translation of his patch), so I'm not 100% 
confident I wouldn't unwittingly introduce screwy combinations with a 
more fine-grained set of config options (mostly w.r.t. to the LPC & iLPC 
stuff).

>> diff --git a/arch/arm/mach-aspeed/Kconfig 
>> b/arch/arm/mach-aspeed/Kconfig
>> index 579a547df61e..2b51f87e0732 100644
>> --- a/arch/arm/mach-aspeed/Kconfig
>> +++ b/arch/arm/mach-aspeed/Kconfig
>> @@ -45,6 +45,18 @@ config ASPEED_AST2600
>>           which is enabled by support of LPC and eSPI peripherals.
>>  endchoice
>>
>> +config ASPEED_ISOLATE_BMC
>> +       bool "Disable hardware features that provide unnecessary access to the BMC"
>> +       depends on ASPEED_AST2500
>> +       default n
>
>all kconfig are "default n", so you can omit this.
>

Ack, thanks.

>I suggest we invert the meaning of the option. The default should be
>turn off the backdoors, and someone can optionally re-enable them by
>selecting the option.
>

I was tempted to make it 'default y' (i.e. secure-by-default), but the 
possibility of compatibility breaks with existing systems that might 
depend on the current insecure-by-default arrangement gave me pause.  If 
we don't think that's a big concern though I'm happy to flip the sense 
of it and have the more aggressive default.

>config ASPEED_ALLOW_BACKDOORS?

Sounds reasonable to me, though maybe s/ALLOW/ENABLE/?


Thanks,
Zev



More information about the openbmc mailing list