This is totally different from the raft of side channel attacks we have
seen recently. It seems much harder to implement, but potentially much
more devastating.

https://www.wired.com/story/amd-chip-sinkclose-flaw/


--
- Stephen Fuld
(e-mail address disguised to prevent spam)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

MitchAlsup1 wrote:

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

Probably sufficient, but not necessary. Apparently Intel chips are not vulnerable to this particular atack.



--
- Stephen Fuld
(e-mail address disguised to prevent spam)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 9 Aug 2024 17:52:50 +0000, Stephen Fuld wrote:

MitchAlsup1 wrote:

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

Probably sufficient, but not necessary.

Eliminates the need for ring -1 and ring -2.

Apparently Intel chips are not vulnerable to this particular atack.

So far.....



--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

mitchalsup@aol.com (MitchAlsup1) writes:

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

How would that help?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

mitchalsup@aol.com (MitchAlsup1) writes:

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.

If a few instructions in the flash get changed, the digital
signature check will fail and the on-chip ROM will refuse
to load it from flash.

(Unless the OEM is breathtakingly incompetent and
uses sample keys instead of generating their when building
the firmware image).

https://arstechnica.com/security/2024/07/secure-boot-is-completely-compromised-on-200-models-from-5-big-device-makers/?comments=1&comments-page=1

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)