[coreboot] Source code for "Intel Firmware"

[Zvi Vered]

Hello,

A bin file burned on a BIOS chip contains "Intel FW":

Intel FW = IFD +PD+ME/TXE+GBE

IFD=Intel Firmware Descriptor Table.
PD=Parameters
ME=Management Engine (For "Core" kind of processors).
TXE=Trusted Execution Engine (For "Atom" kind of processors).
GBE=Network card firmware.

If I'm not mistaken, this package is not supplied within coreboot.

coreboot only replaces the BIOS part developed by vendors like "AMI bios".

Where can I find full source code for "Intel FW" ?

Currently, in order to replace vendor's BIOS we must take binary parts
of the original bin file and then stitch it to coreboot.rom built with
the coreboot project.

I want to depend only on Intel.

Thank you,
Zvika

[Nico Huber]

Post by Zvi Vered
Hello,
Intel FW = IFD +PD+ME/TXE+GBE
IFD=Intel Firmware Descriptor Table.
PD=Parameters
ME=Management Engine (For "Core" kind of processors).
TXE=Trusted Execution Engine (For "Atom" kind of processors).
GBE=Network card firmware.
If I'm not mistaken, this package is not supplied within coreboot.

Right.

Post by Zvi Vered
coreboot only replaces the BIOS part developed by vendors like "AMI bios".

Yes, mostly. For some platforms, coreboot also replaces reference code
of the silicon vendor, but today it's mostly just what an IBV like AMI
does.

Post by Zvi Vered
Where can I find full source code for "Intel FW" ?

Most of the regions you mentioned above don't contain code at all.
Beside the BIOS, there is ME/TXE code but Intel provides only binaries
for these, AFAIK.

Post by Zvi Vered
Currently, in order to replace vendor's BIOS we must take binary parts
of the original bin file and then stitch it to coreboot.rom built with
the coreboot project.
I want to depend only on Intel.

That is possible but will require you to dive even deeper in Intel's
platform configuration. I can only advice you to treat each of the
firmware parts individually as much as possible. For instance, first
try to replace the BIOS with coreboot (while keeping the original other
parts), then try to replace the ME/TXE firmware, then the GBE and IFD
(the latter both only contain configuration data, AFAIK).

You will need an NDA with Intel. Then ask them for their binaries, docu-
mentation and (Windows) tools to create your own configuration.

Don't underestimate the effort. You'll probably need some months to get
your own coreboot running, then few more to read through all the docu-
mentation and craft your own IFD etc.

Nico

[Zvi Vered]

Hello Nathaniel, Nico,

Thank you very much for the detailed answers.

The vendor's bin file starts with the following pattern:
00000000: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
00000010: 5AA5F00F 03000402 0602100B 20002100

Can you confirm that this is the start of IFD ?

Best regards,
Zvika

Post by Nico Huber

Post by Zvi Vered
Hello,
Intel FW = IFD +PD+ME/TXE+GBE
IFD=Intel Firmware Descriptor Table.
PD=Parameters
ME=Management Engine (For "Core" kind of processors).
TXE=Trusted Execution Engine (For "Atom" kind of processors).
GBE=Network card firmware.
If I'm not mistaken, this package is not supplied within coreboot.

Right.

Post by Zvi Vered
coreboot only replaces the BIOS part developed by vendors like "AMI bios".

Yes, mostly. For some platforms, coreboot also replaces reference code
of the silicon vendor, but today it's mostly just what an IBV like AMI
does.

Post by Zvi Vered
Where can I find full source code for "Intel FW" ?

Most of the regions you mentioned above don't contain code at all.
Beside the BIOS, there is ME/TXE code but Intel provides only binaries
for these, AFAIK.

Post by Zvi Vered
Currently, in order to replace vendor's BIOS we must take binary parts
of the original bin file and then stitch it to coreboot.rom built with
the coreboot project.
I want to depend only on Intel.

That is possible but will require you to dive even deeper in Intel's
platform configuration. I can only advice you to treat each of the
firmware parts individually as much as possible. For instance, first
try to replace the BIOS with coreboot (while keeping the original other
parts), then try to replace the ME/TXE firmware, then the GBE and IFD
(the latter both only contain configuration data, AFAIK).
You will need an NDA with Intel. Then ask them for their binaries, docu-
mentation and (Windows) tools to create your own configuration.
Don't underestimate the effort. You'll probably need some months to get
your own coreboot running, then few more to read through all the docu-
mentation and craft your own IFD etc.
Nico

[Angel Pons]

Hello Zvika,

Post by Zvi Vered
00000000: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
00000010: 5AA5F00F 03000402 0602100B 20002100
Can you confirm that this is the start of IFD ?

The magic "5A A5 F0 0F" at offset 0x10 indicates the start of the IFD.

Regards,

Angel Pons

[Nico Huber]

Post by Zvi Vered
Hello Nathaniel, Nico,
Thank you very much for the detailed answers.
00000000: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
00000010: 5AA5F00F 03000402 0602100B 20002100
Can you confirm that this is the start of IFD ?

Yes, it is (at least the first 20B are distinctive).

There is not much public documentation about it ([1] is all I know)
but you might find something less public with Google [2]. There's also
a lot of open-source code of programs that can parse it [3][4]. Code
is usually more accurate than documentation but it explains less about
the configuration bits. You'll have to ask Intel for the SPI Program-
ming Guide for your particular platform if you want to fully under-
stand it and craft your own.

Nico

[1]
https://review.coreboot.org/cgit/flashrom.git/plain/Documentation/mysteries_intel.txt
[2] "Intel" "SPI" "Programming Guide" *cough
[3] https://review.coreboot.org/cgit/flashrom.git/tree/ich_descriptors.c
[4] https://review.coreboot.org/cgit/coreboot.git/tree/util/ifdtool/

[Zvi Vered]

Hi Nico,

Thank you very much for the information.

Best regards,
Zvika

Post by Nico Huber

Post by Zvi Vered
Hello Nathaniel, Nico,
Thank you very much for the detailed answers.
00000000: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
00000010: 5AA5F00F 03000402 0602100B 20002100
Can you confirm that this is the start of IFD ?

Yes, it is (at least the first 20B are distinctive).
There is not much public documentation about it ([1] is all I know)
but you might find something less public with Google [2]. There's also
a lot of open-source code of programs that can parse it [3][4]. Code
is usually more accurate than documentation but it explains less about
the configuration bits. You'll have to ask Intel for the SPI Program-
ming Guide for your particular platform if you want to fully under-
stand it and craft your own.
Nico
[1]
https://review.coreboot.org/cgit/flashrom.git/plain/Documentation/mysteries_intel.txt
[2] "Intel" "SPI" "Programming Guide" *cough
[3] https://review.coreboot.org/cgit/flashrom.git/tree/ich_descriptors.c
[4] https://review.coreboot.org/cgit/coreboot.git/tree/util/ifdtool/

[ron minnich]

Post by Zvi Vered
coreboot only replaces the BIOS part developed by vendors like "AMI bios".

Just to make it clear, it was not always this way.

In 1999, 100% of what we call coreboot did 100% of the tasks, and by 2002
it worked on x86, x86_64, powerpc, and alpha-- all 100% GPL.

See slide 17 in
https://docs.google.com/presentation/d/1-_cgb4gRhZxl9anxudIgO_NAB80yq-ks4HtOx-zlDz8/edit?usp=sharing
from
2012.
This table shows the fraction of the ROM that is developed with GPL'ed code.
That table was made in 2012; as of 2018, AMD is no more open than intel.
Probably around 10% at most of the x86 ROM space consists of GPL code.

Starting in 2004, Intel pushed back hard on this open situation and we have
ended up where we are today: significant amounts of binary blobs in
coreboot images on x86.

PLEASE, let's not start another "bad intel!" discussion again. There are
lots of people at Intel who are working hard to change back to the
more open model.

Intel is a business and the higher ups at Intel made what they thought were
the right business decisions at the time. We don't agree, and let's leave
it at that.

I just wanted to point out that in the history of microprocessors, from
1970 to present, this current closed situation is not normal.

if you really want 100% open, the only real options at this point are power
9, RISCV and some ARM CPUs.

ron

[Andrew Luke Nesbit]

[...]

if you really want 100% open, the only real options at this point are power 9, RISCV and some ARM CPUs.

Ron, thanks for your reasoned reply and the contextual background. I believe this is important when embarking on any project with a legacy.

I know of libre-friendly POWER9 and RISC-V options. For example, I am currently learning my way around the Talos II (which is excellent). ARM-based systems have been elusive to me.

Could you please give some examples of fully libre-friendly ARM-based boards or systems? Thanks!!

Kind regards,

Andrew

[ron minnich]

It depends on what you mean by fully. If there is a so-called Mask ROM
(i.e. initial boot program that's part of the chip itself, not replaceable,
you can disassemble it however) and the rest of the chip is fully open,
does that count?

For my money the ARM chromebooks are still one of the best bets out there
for messing about with ARM firmware.

On Sat, Oct 6, 2018 at 12:30 PM Andrew Luke Nesbit <

[...]

Post by ron minnich
if you really want 100% open, the only real options at this point are

power 9, RISCV and some ARM CPUs.
Ron, thanks for your reasoned reply and the contextual background. I
believe this is important when embarking on any project with a legacy.
I know of libre-friendly POWER9 and RISC-V options. For example, I am
currently learning my way around the Talos II (which is excellent).
ARM-based systems have been elusive to me.
Could you please give some examples of fully libre-friendly ARM-based
boards or systems? Thanks!!
Kind regards,
Andrew

[Andrew Luke Nesbit]

It depends on what you mean by fully. If there is a so-called Mask ROM (i.e. initial boot program that's part of the chip itself, not replaceable, you can disassemble it however) and the rest of the chip is fully open, does that count?

That's a good start. In my experience, these are what I've mostly seen.

Ideally I mean one where the boot loader (and payload?) are not proprietary. Or that an open source boot loader could be used, preferably without added blobs.

For my money the ARM chromebooks are still one of the best bets out there for messing about with ARM firmware.

Yes, I've been looking at getting one for this very purpose, especially as it's already a whole, usable system. Have you any particular recommendations?

Post by Andrew Luke Nesbit
[...]

if you really want 100% open, the only real options at this point are power 9, RISCV and some ARM CPUs.

Ron, thanks for your reasoned reply and the contextual background. I believe this is important when embarking on any project with a legacy.
I know of libre-friendly POWER9 and RISC-V options. For example, I am currently learning my way around the Talos II (which is excellent). ARM-based systems have been elusive to me.
Could you please give some examples of fully libre-friendly ARM-based boards or systems? Thanks!!
Kind regards,
Andrew

[ron minnich]

There are people on this list who know better than I what the most "open"
one is.

Anyone out there have some advice?

On Sat, Oct 6, 2018 at 3:17 PM Andrew Luke Nesbit <

Post by ron minnich
It depends on what you mean by fully. If there is a so-called Mask ROM
(i.e. initial boot program that's part of the chip itself, not replaceable,
you can disassemble it however) and the rest of the chip is fully open,
does that count?
That's a good start. In my experience, these are what I've mostly seen.
Ideally I mean one where the boot loader (and payload?) are not
proprietary. Or that an open source boot loader could be used, preferably
without added blobs.
For my money the ARM chromebooks are still one of the best bets out there
for messing about with ARM firmware.
Yes, I've been looking at getting one for this very purpose, especially as
it's already a whole, usable system. Have you any particular
recommendations?
On Sat, Oct 6, 2018 at 12:30 PM Andrew Luke Nesbit <

[...]

Post by ron minnich
if you really want 100% open, the only real options at this point are

power 9, RISCV and some ARM CPUs.
Ron, thanks for your reasoned reply and the contextual background. I
believe this is important when embarking on any project with a legacy.
I know of libre-friendly POWER9 and RISC-V options. For example, I am
currently learning my way around the Talos II (which is excellent).
ARM-based systems have been elusive to me.
Could you please give some examples of fully libre-friendly ARM-based
boards or systems? Thanks!!
Kind regards,
Andrew

[Merlin Büge]

On Sat, 6 Oct 2018 16:24:15 -0700

Post by ron minnich
There are people on this list who know better than I what the most
"open" one is.
Anyone out there have some advice?

These are interesting:

Samsung Chromebook Plus (based on RK3399, not available in EU) and
Asus Chromebook R13

"ECC'17: Run upstream coreboot on an ARM Chromebook"

Cheers, Merlin

Post by ron minnich
On Sat, Oct 6, 2018 at 3:17 PM Andrew Luke Nesbit <

Post by ron minnich
It depends on what you mean by fully. If there is a so-called Mask
ROM (i.e. initial boot program that's part of the chip itself, not
replaceable, you can disassemble it however) and the rest of the
chip is fully open, does that count?
That's a good start. In my experience, these are what I've mostly seen.
Ideally I mean one where the boot loader (and payload?) are not
proprietary. Or that an open source boot loader could be used,
preferably without added blobs.
For my money the ARM chromebooks are still one of the best bets out
there for messing about with ARM firmware.
Yes, I've been looking at getting one for this very purpose,
especially as it's already a whole, usable system. Have you any
particular recommendations?
On Sat, Oct 6, 2018 at 12:30 PM Andrew Luke Nesbit <

[...]

Post by ron minnich
if you really want 100% open, the only real options at this point are

power 9, RISCV and some ARM CPUs.
Ron, thanks for your reasoned reply and the contextual
background. I believe this is important when embarking on any
project with a legacy.
I know of libre-friendly POWER9 and RISC-V options. For example,
I am currently learning my way around the Talos II (which is
excellent). ARM-based systems have been elusive to me.
Could you please give some examples of fully libre-friendly
ARM-based boards or systems? Thanks!!
Kind regards,
Andrew

[Philipp Stanner]

Post by Zvi Vered
Currently, in order to replace vendor's BIOS we must take binary parts
of the original bin file and then stitch it to coreboot.rom built with
the coreboot project.

Well, exactly. Why do you think that is? Intel won't give you or anyone
that code. Their policy seems to be to hide as much source code as
possible.
I don't know why they contribute so much to the Linux Kernel, though…

Post by Zvi Vered
I want to depend only on Intel.

?
You do depend on Intel. You depend on them not doing awkward stuff on
their machines (what they clearly do, running Minix within the whole
"BIOS").

[Nico Huber]

Post by Philipp Stanner

Post by Zvi Vered
Currently, in order to replace vendor's BIOS we must take binary parts
of the original bin file and then stitch it to coreboot.rom built with
the coreboot project.

Well, exactly. Why do you think that is? Intel won't give you or anyone
that code. Their policy seems to be to hide as much source code as
possible.

At least since I'm working on the project it was always like this. And,
IMHO, it is a good thing. The only decent x86 coreboot code I know was
written when Intel didn't have their fingers in the pie. Without source
code available, people had to write clean code. If you compare this to
coreboot code that is closer to vendor code or was contributed by sili-
con vendors... there are some levels of quality and maintainability in
between.

So what we need is documentation not code, IMHO.

Post by Philipp Stanner
I don't know why they contribute so much to the Linux Kernel, though…

Post by Zvi Vered
I want to depend only on Intel.

?
You do depend on Intel. You depend on them not doing awkward stuff on
their machines (what they clearly do, running Minix within the whole
"BIOS").

Minix runs on the Management Engine (ME). It's completely separate from
the "BIOS".

Nico

[Philipp Stanner]

Hey Nico,

Post by Nico Huber
At least since I'm working on the project it was always like this. And,
IMHO, it is a good thing. The only decent x86 coreboot code I know was
written when Intel didn't have their fingers in the pie.

Do the Intel engineers write bad code in your opinion? One would
believe that those who know their platform best and get paid to work on
it 8 hours a day produce nothing of bad quality… :|

Post by Nico Huber
Minix runs on the Management Engine (ME). It's completely separate from
the "BIOS".

My bad, I knew that actually. Some more madness. Sometimes it confuses
you when you find out that hell has several levels and hierarchies.

P.

[Peter Stuge]

Post by Philipp Stanner

Post by Nico Huber
The only decent x86 coreboot code I know was
written when Intel didn't have their fingers in the pie.

Do the Intel engineers write bad code in your opinion?

We can't really know, because they don't publish their (firmware) code.

But their chosen (firmware) architecture is unneccessarily complicated;
that's not a choice technical experts would make.

We do however know what consequences said (firmware) architecture have
for coreboot, both the good and the bad.

Post by Philipp Stanner
One would believe that those who know their platform best and get
paid to work on it 8 hours a day produce nothing of bad quality… :|

Please remember that Intel is a parts supplier for machines.

Software is merely a supporting act for hardware sales, and I think that
shows clearly with Intel, as it does with most hardware companies.


//Peter

[Philipp Stanner]

Post by Peter Stuge
We do however know what consequences said (firmware) architecture have
for coreboot, both the good and the bad.

What's the good?

[Nico Huber]

Post by Philipp Stanner

Post by Peter Stuge
We do however know what consequences said (firmware) architecture have
for coreboot, both the good and the bad.

What's the good?

I can think of one: compatibility.

On x86 for instance, coreboot is used to have the same reset vector and
partially the same bootblock for every platform. The hardware isn't the
same, though, and it (probably) can't run in the same way any more. It's
some ROM code (maybe sometimes from flash too?) that actually prepares
what is necessary so we can keep the same software model in coreboot.

Nico

[Peter Stuge]

Post by Philipp Stanner

Post by Peter Stuge
We do however know what consequences said (firmware) architecture
have for coreboot, both the good and the bad.

What's the good?

Adoption.


//Peter

[Nico Huber]

Post by Philipp Stanner
Hey Nico,

Post by Nico Huber
At least since I'm working on the project it was always like this. And,
IMHO, it is a good thing. The only decent x86 coreboot code I know was
written when Intel didn't have their fingers in the pie.

Do the Intel engineers write bad code in your opinion? One would
believe that those who know their platform best and get paid to work on
it 8 hours a day produce nothing of bad quality… :|

They are not experts in software development. And the employees that
write the software are not the ones who know the platforms best.

My impression is that they have no idea at all what they are doing
and just test and fix as hell until it works somehow. I don't think
that this is the developer's fault, though. Political decisions about
software design which frameworks and tools to use etc. can get ugly
code out of any developer. Taking FSP (or BIOS reference code gene-
rally) for example, I guess the actual silicon init makes about 5 to
10% of the code. Everything else is just there to keep the developers
from doing a good job.

So the result is probably that they work half an hour instead of 8
per day on the code that matters.

Nico

[ron minnich]

Post by Nico Huber
So the result is probably that they work half an hour instead of 8
per day on the code that matters.

good summary.

The most security critical code gets the least attention and no external
security review.

If this sounds crazy, well ... it is.

[Philipp Stanner]

good summary. 
The most security critical code gets the least attention and no
external security review. 
If this sounds crazy, well ... it is.

I honestly don't think that matters at all. Worrying about crappy BIOS
code while a real time surveilance tool like the IME is on the system
is like complaining about missing sweets on a sinking ocean liner.

[Nico Huber]

This post might be inappropriate. Click to display it.