Re: Downfall microcode update

> Updating the CPU microcode _after_ the kernel has started

Kernel does lot of stuff "after it starts" running,
after it gets loaded, before userland, so really
your note means next possible place to "updating"
is after kernel hands off to init.

> seems questionable.

Yes it's supposed to go in from bios before
executing any other code (ie from disk).

So unless you able to rebuild your own bios images
on old boards whose makers are too lame to support
updates from upstream cpu vendor, then the next earliest and
thus most correct way is have loader load it into cpu first...
in case kernel does use the cpu ops that the ucode modifies.

The rc way could be there for easier config switch from
bad ucode in single user mode. At least Intel has
revoked at least one ucode for problems before,
but probably not yet for one that locked up anyone's
basic kernel load, boot, or user shell.

So rc kindof doesn't need to exist given loader way,
and that reboot repair methods still exist.

> cron

From the HW vendors cpu repos could work, no need
to hammer fbsd site for that, but a bit overkill unless you're
a shared hosting service, the big guys get advance notice anyway.
Nor is anyone sane doing cron fetch and installworld to
apply new code either like that.