[PATCH u-boot v2019.04-aspeed-openbmc v2] aspeed: add CONFIG_ASPEED_ENABLE_BACKDOORS
Ryan Chen
ryan_chen at aspeedtech.com
Fri Apr 15 18:11:09 AEST 2022
Hello,
Thanks your response.
And yes, I prefer apply patch without any config to disable it.
Ryan
> -----Original Message-----
> From: Zev Weiss <zev at bewilderbeest.net>
> Sent: Friday, April 15, 2022 4:04 PM
> To: Ryan Chen <ryan_chen at aspeedtech.com>
> Cc: Joel Stanley <joel at jms.id.au>; openbmc at lists.ozlabs.org; Andrew Jeffery
> <andrew at aj.id.au>
> Subject: Re: [PATCH u-boot v2019.04-aspeed-openbmc v2] aspeed: add
> CONFIG_ASPEED_ENABLE_BACKDOORS
>
> On Thu, Apr 14, 2022 at 08:21:00PM PDT, Ryan Chen wrote:
> >Hello Zev,
> > I don't think it is good to send a patch to enable security backdoor.
> > It should not be enabled, even it user aware it.
> > That will cause big issues in BMC.
> >
>
> Hi Ryan,
>
> To clarify, the current state of the code leaves the backdoors enabled on
> ast2400 and ast2500 (insecure/debug mode), with no easy way to turn them
> off.
>
> With this patch they'll be turned off by default (secure/production mode), but a
> user that wants to turn them back on can still do so if they explicitly request it
> via the new Kconfig option. The name and description of the option I think
> make it pretty clear that it's for debugging only and shouldn't be enabled on
> production systems.
>
> Is your opinion that we should apply something like this patch, but without any
> configurability at all? I think having the option available to leave the
> backdoors on could be worthwhile (I've found the debug UART useful now and
> then during my own development work, for example) as long as the security
> implications are clearly indicated. It wouldn't be the first Kconfig option
> that's really only appropriate for development and shouldn't be enabled in a
> production build (e.g. ASPEED_PALLADIUM).
>
>
> Thanks,
> Zev
More information about the openbmc
mailing list