Re: A different type of security vulnerability

On Sat, 10 Aug 2024 17:23:08 +0000, Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

On Fri, 9 Aug 2024 20:22:55 +0000, Scott Lurndal wrote:
>

mitchalsup@aol.com (MitchAlsup1) writes:

If only x86 chips came out of RESET with the MMUs
already turned on.

>
How would that help?

>
Code/data cannot be accessed from places not permitted by the
mapping tables--especially places meant to be secure as
mentioned in the above article.

>
Who sets up the page table?

The people who write BOOT code

When the chip comes out of reset, the firmware (which must,
by definition, be trusted/secure) is the only software running and
it must have complete control of the machine if only for
the various proprietary initialization sequences that need
to be run for e.g. PCIe link training, inter-chiplet link
setup and training, configuring the ring/switch/mesh fabric,
LLC slices, bridge setup (i.e. routing MMIO accesses to
the appropriate destination when initiated by a core),
reading SPDs and training DRAM controllers, etc.

All of the above it true. But consider what happens when a few
instructions in the ROM get <flash> changed making the BOOT
code insecure. Without an MMU, the patch could go anywhere and
be malicious; it is much harder if the MMU is up and running.
Add a chip persistent ROM sum-check, and it becomes very hard.