Change in ...coreboot[master]: soc/intel/basecode: Add support for updating ucode loaded via FIT

[Nico Huber (Code Review)]

Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/27369 )

Change subject: soc/intel/basecode: Add support for updating ucode loaded via FIT
......................................................................

Patch Set 33:
> > The more I'm thinking about this the more I realize that I don't
> > understand the purpose of this update mechanism.
> >
> > For being able to perform the update, you already need a RO MCU that
> > works good enough to get you to ramstage. At this point, you can
> > already apply additional MCUs from any RW partition. So what kind of
> > issue would have to be fixed by an update that makes use of this
> > mechanism?
> >
> > In other words, what problem can this new update mechanism fix, that
> > current mechanisms can't? And is it worth the added complexity and
> > accompanying security degradation (more code is always more error-
> > prone)?
>
> Microcode patch contains patch for Punit as well, and that has to
> be applied prior to reset.

Ah, understood. Thanks for the clarification.

Ofc, it's too late for current products. But is there any change
planned for the FIT update mechanism. e.g. a rule that multiple
updates for one processor signature are allowed and the newest would
be applied. That would make this much easier, would allow a single
RO FIT with some entries pointing to RO and some to the MCU RW and
we wouldn't need the top-swap feature any more.
> Hence the effort to load the updated microcode via FIT.

This is probably the most urgent thing to mention in the commit
message. Without this reasoning, it looks like you are just playing
around and Intel adds complexity just because they can.