Modern CPUs have a backstage cast
by Hugo Landau, 2023-05-30
- https://www.devever.net/~hl/backstage-cast

"If you take someone with intermediate knowledge of computing in the
right areas, and ask them how an x86 machine boots, they'll
probably start telling you about how the CPU first comes up in real
mode and starts executing code from the 8086 reset vector of
FFFF:FFF0. This understanding of how an x86 machine boots has
remained remarkably persistent, as far as I can tell because this
basic narrative about the boot process has been handed down from
website to website, generation to generation, largely unchanged.

It's also a pack of lies and hasn't reflected the true nature of
the boot process for some time. It's true the 8086 reset vector is
still used, but only because it's a standard "ABI" for the CPU to
transfer control to the BIOS (whether legacy PC BIOS or UEFI BIOS).
In reality an awful lot happens before this reset vector starts
executing.1 Aside from people having vaguely heard about the Intel
Management Engine, this modern reality of the boot process remains
largely unknown. It doesn't help that neither Intel nor AMD have
really gone out of their way to actually document what the modern
boot process looks like, and large parts of this process are
handled by vendor-supplied mystery firmware blobs, which may as
well be boxes with "???" written in them. Mainly we have the
substantial assistance of assorted reverse engineers and security
researchers to thank for the fact that we even have a decent
picture of what the modoern x86 boot process actually looks like
for both Intel and AMD. I could write a whole article about that
process -- but instead, I'd like to focus on something else.

Basically any multiprocessor CPU chip of reasonable sophistication
produced today -- i.e., desktop and server CPUs, and probably
smartphone SoCs for that matter, also has an entire "backstage
cast" of ancillary support cores keeping things running correctly.
Some of these mainly handle the boot process, and we're more likely
to know about these (e.g. Intel ME/AMD PSP), but even less known
are "backstage" cores which don't participate in the boot process
but which are instead involved in things like power and thermal
regulation." ...

--
__ __
#_ < |\| |< _#

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

On 9/24/23 17:37, Computer Nerd Kev wrote:

Modern CPUs have a backstage cast
by Hugo Landau, 2023-05-30
- https://www.devever.net/~hl/backstage-cast

"If you take someone with intermediate knowledge of computing in the
right areas, and ask them how an x86 machine boots, they'll
probably start telling you about how the CPU first comes up in real
mode and starts executing code from the 8086 reset vector of
FFFF:FFF0. This understanding of how an x86 machine boots has
remained remarkably persistent, as far as I can tell because this
basic narrative about the boot process has been handed down from
website to website, generation to generation, largely unchanged.

It's also a pack of lies and hasn't reflected the true nature of
the boot process for some time. It's true the 8086 reset vector is
still used, but only because it's a standard "ABI" for the CPU to
transfer control to the BIOS (whether legacy PC BIOS or UEFI BIOS).
In reality an awful lot happens before this reset vector starts
executing.1 Aside from people having vaguely heard about the Intel
Management Engine, this modern reality of the boot process remains
largely unknown. It doesn't help that neither Intel nor AMD have
really gone out of their way to actually document what the modern
boot process looks like, and large parts of this process are
handled by vendor-supplied mystery firmware blobs, which may as
well be boxes with "???" written in them. Mainly we have the
substantial assistance of assorted reverse engineers and security
researchers to thank for the fact that we even have a decent
picture of what the modoern x86 boot process actually looks like
for both Intel and AMD. I could write a whole article about that
process -- but instead, I'd like to focus on something else.

Basically any multiprocessor CPU chip of reasonable sophistication
produced today -- i.e., desktop and server CPUs, and probably
smartphone SoCs for that matter, also has an entire "backstage
cast" of ancillary support cores keeping things running correctly.
Some of these mainly handle the boot process, and we're more likely
to know about these (e.g. Intel ME/AMD PSP), but even less known
are "backstage" cores which don't participate in the boot process
but which are instead involved in things like power and thermal
regulation." ...

Company secrecy is so frustrating sometimes.
--
--
user <candycane> is generated from /dev/urandom

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

Am 24.09.2023 um 20:16:35 Uhr schrieb candycanearter07:

On 9/24/23 17:37, Computer Nerd Kev wrote:

Basically any multiprocessor CPU chip of reasonable sophistication
produced today -- i.e., desktop and server CPUs, and probably
smartphone SoCs for that matter, also has an entire "backstage
cast" of ancillary support cores keeping things running correctly.
Some of these mainly handle the boot process, and we're more
likely to know about these (e.g. Intel ME/AMD PSP), but even less
known are "backstage" cores which don't participate in the boot
process but which are instead involved in things like power and
thermal regulation." ...

Company secrecy is so frustrating sometimes.

Intel ME had serious security issues in the past. If people really know
what they do and can proof that, the will maybe never every buy Intel
CPUs because of the security issues.

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

Will such things end in the RISC-V era?

Probably not.

ISA extensions to the open RISC-V definitions and the helpers around the
CPU still may be kept closed. Only systems where we get each gate of
the whole system documented can prove not to do such things.

So I hope that this project still lives and continues:

Self-Hosting (Almost) All The Way Down
A FPGA-based Fedora-capable computer that can rebuild its own bitstream <https://archive.fosdem.org/2023/schedule/event/rv_selfhosting_all_the_way_down/>

But then we still have to trust the FPGA chip's contents. *sigh*

Hopefully someone has ideas how to verify them to be free of backdoors.

--
This stealth signature intentionally left blank.

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

yeti <yeti@tilde.institute> wrote:

Will such things end in the RISC-V era?

Probably not.

ISA extensions to the open RISC-V definitions and the helpers around the
CPU still may be kept closed. Only systems where we get each gate of
the whole system documented can prove not to do such things.

So I hope that this project still lives and continues:

Self-Hosting (Almost) All The Way Down
A FPGA-based Fedora-capable computer that can rebuild its own bitstream <https://archive.fosdem.org/2023/schedule/event/rv_selfhosting_all_the_way_down/>

Interesting. But going from the benchmarks in the linked research
paper, it's a long way behind the standards of "modern CPUs" at
65MHz clock speed. I haven't watched the video yet, but it looks
like 100MHz is their current maximum clock speed with "proprietary
non-FOSS HDL toolchain (Vivado)".

Still interesting, but so long as software like web browsers
continue to bloat up to the limits of current hardware, I don't see
the FPGA CPU approach being more than an extremely obscure niche.

IBM's OpenPOWER CPUs, like POWER9 in the first article, might be
the closest that you can get to a practical open CPU design. You
just have to trust that IBM really make chips matching the
published designs.

But then we still have to trust the FPGA chip's contents. *sigh*

Hopefully someone has ideas how to verify them to be free of backdoors.

It depends whether the people behind that project are right that
there can't be silicon-level backdoors in the FPGAs themselves. I
doubt there are _now_ because it's such a niche, but if millions of
FPGAs were selling for use with one or two dominate CPU
applications, I think it would be pretty easy for governments to
force manufacturers to sneek sub-systems into the FPGA chips that
could influence the behaviour of the most popular core designs.

Someone did build a RISC-V CPU from discrete logic chips, which
really could be fully verified for backdoors: https://spectrum.ieee.org/build-a-riscv-cpu-from-scratch

But it runs at under 1MHz.

--
__ __
#_ < |\| |< _#

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

not@telling.you.invalid (Computer Nerd Kev) writes:

Interesting. But going from the benchmarks in the linked research
paper, it's a long way behind the standards of "modern CPUs" at
65MHz clock speed. I haven't watched the video yet, but it looks
like 100MHz is their current maximum clock speed with "proprietary
non-FOSS HDL toolchain (Vivado)".

Still interesting, but so long as software like web browsers
continue to bloat up to the limits of current hardware, I don't see
the FPGA CPU approach being more than an extremely obscure niche.

I think a system able to rebuild itself down to the bitstream is an
extreme important milestone and I don't care about browsers now. Sure
more speed, cores and RAM is needed and that will happen. If not
exactly in that project, then in a similar one.

There is a RISC-V/32 Linux that even runs on an iCE40Up5K and sure that
still has it's own limitations and is not even capable to rebuild its
own bitstream, but maybe in a future iteration?

<https://github.com/smunaut/iCE40linux>

Why not use one FPGA per CPU? Maybe even own chips for complex parts of
the periphery? That might even help the rebuild process to be more
incremental and less disruptive.

It'll take some time until the full-fat bloat will run on such systems,
maybe even so long that meanwhile the data cattle has woken up and
insists in safer browsers, no JS, ... *just-dreaming*

I have some iCE40UP5K and -HX8K boards, but not the right RAMs and sure
I still am in the toddler group of Verilog users. But I really love to
see such projects. There is hope.

Stay OmmmmmmPtimistic!

--
How long does it take until each GNUtility is Turing-complete?

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