RE: [PATCH u-boot v2019.04-aspeed-openbmc v2] aspeed: add CONFIG_ASPEED_ENABLE_BACKDOORS

[Ryan Chen <ryan_chen@aspeedtech.com>]

Hello,
	Thanks your response.
	And yes, I prefer apply patch without any config to disable it.

Ryan

> -----Original Message-----
> From: Zev Weiss <zev@bewilderbeest.net>
> Sent: Friday, April 15, 2022 4:04 PM
> To: Ryan Chen <ryan_chen@aspeedtech.com>
> Cc: Joel Stanley <joel@jms.id.au>; openbmc@lists.ozlabs.org; Andrew Jeffery
> <andrew@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