Am Samstag, den 06.10.2018, 07:50 +0300 schrieb 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…
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").
On 10/7/18 10:10 PM, Philipp Stanner wrote:
Am Samstag, den 06.10.2018, 07:50 +0300 schrieb 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.
I don't know why they contribute so much to the Linux Kernel, though…
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
Hey Nico,
Am Sonntag, den 07.10.2018, 22:56 +0200 schrieb 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… :|
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.
Philipp Stanner wrote:
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.
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
Am Mittwoch, den 10.10.2018, 11:01 +0000 schrieb Peter Stuge:
We do however know what consequences said (firmware) architecture have for coreboot, both the good and the bad.
What's the good?
On 10/12/18 6:09 PM, Philipp Stanner wrote:
Am Mittwoch, den 10.10.2018, 11:01 +0000 schrieb 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
On 10/9/18 6:59 PM, Philipp Stanner wrote:
Hey Nico,
Am Sonntag, den 07.10.2018, 22:56 +0200 schrieb 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
On Sat, Oct 13, 2018 at 10:25 AM Nico Huber nico.h@gmx.de wrote:
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.
-
Nico Huber -
Peter Stuge -
Philipp Stanner -
ron minnich