[XS] Change in coreboot[main]: security/vboot: Add option for enabling ADB over network via GBB flag

[Subrata Banik (Code Review)]

Attention is currently required from: Jon Murphy, Julius Werner, Kapil Porwal, Yu-Ping Wu.

Subrata Banik has posted comments on this change by Subrata Banik. ( https://review.coreboot.org/c/coreboot/+/87031?usp=email )

Change subject: security/vboot: Add option for enabling ADB over network via GBB flag
......................................................................

Patch Set 1:

(1 comment)

Patchset:

PS1:
> I'm not really sure what we're talking about here anymore. My current understanding is that this GBB flag is not the intended long-term solution for controlling ADB access.

GBB flag is the only way to control the ADB at this moment as documented in go/al-care#external-adb-over-tcp-access-permanently, this should remain in effect unless updated.
> If that is the case, it should not land on the main branch. The main branch is for finalized, long-term solutions. We have a separate branch for the temporary bring-up hacks for a reason.

As Jon mentioned, the coreboot project is in sync for both the main branch and AL FW branch, so we can't land this CL in just the AL FW branch without also landing it in mainline.
> If my understanding is not correct and you do want to keep this flag long-term, then we need to have a design doc and a discussion about why this should be a GBB flag in the first place.

There might be alternative long-term solutions, but my point is that the current coreboot code should handle whatever draftd is currently using. There's no harm in this approach, and if a revised solution comes along, we can always revert this CL. Just because the long-term solution is still being determined, doesn't mean we shouldn't enable ADB by default using GBB for all serial AP FW to enable most of the engineering features.
> Right now, the latest doc I'm aware of is go/al-new-products-per-device which seems to suggest that we don't keep this flag. (We would probably then also want to reassign this to the next bit available and not randomly use 31.)

The doc you shared (go/al-new-products-per-device) is still under review, while the spec you're referencing (go/al-care#external-adb-over-tcp-access-permanently) is already in use. I'm not sure how practical it is to compare the two. If go/al-new-products-per-device gets approved and a long-term solution is worked out, then that recommendation will definitely be propagated into AL-care in the future. That can then be used to revert the usage of GBB in the future, to revert ADB enablement.