Re: [coreboot] Proposal: "Freedom level" field for boards

[taii...@gmx.com]

On 02/05/2017 09:09 PM, Daniel Kulesz via coreboot wrote:


  supported by coreboot
Message-Id: <20170206030901.a2ac00bcd93e316782a3e...@googlemail.com>
X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi Timothy,


I have taken much of the feedback received into account, and revised the
freedom level categories at
https://www.coreboot.org/Board_freedom_levels somewhat.  Specifically,
the "Pwned" category is now factually stated as "Vendor Controlled", and
the EC exception in the Silver category was removed, among other minor
tweaks.

These changes had the effect of demoting all Lenovo laptops to Bronze,
and promoting the ASUS C201 (Google Veyron) to Gold.  I am still not
100% sure that I like the Veyron at Gold status due to the WiFi
controller, but I will accept it for now pending introduction of
libre-friendly (firmware-free or HW enforced radio limits with libre
firmware) WiFi chipsets.

Comments welcome!

Generally, I like this revised version. Some minor suggestions:

- if you stress the word "require" in the "vendor controlled" section, I would suggest to stress 
the words "require absolutely no" and "require some" in the above sections.
- the forecast "No amount of reverse engineering or hacking will ever allow a fully libre 
firmware to execute on these boards." sounds too much like a fact and too pesimistic to me to. 
Although it reflects the current state of what we know, I would be careful with making such 
"absolute" forecasts.
- the term "pwned" is still in the introduction.
- I would mention in the introduction that  this is a classification for 
Coreboot-supported boards, not one for boards in general. This is not really clear from 
the introduction. Therefore, I would also state "All coreboot-supported AMD 
hardware" and so on in the vendor-controlled section.
- the term "libre software operating system" is sort of fuzzy, especially as 
you take into account operating systems which ship kernels that contain non-free 
components (at least the FSF claims that).

Cheers, Daniel

Yeah with tens of millions of dollars and a crack team of the best 
hardware engineers in the world I guess you could figure out how to make 
libre firmware boot on a new intel board.


Same as, if you put down a few trillion dollars to do it you could 
colonize mars and have daily commercial flights within the next decade.



So by that standard saying "possible" legitimizes the purism types who 
think that a tiny company that buys quanta laptops is going to some how 
pull it off, it makes people beat a dead x86 horse.



For all intensive purposes it is impossible, the only new libre firmware 
*capable* performance choice at this point is POWER.


--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Proposal: "Freedom level" field for boards

[Daniel Kulesz via coreboot]

 supported by coreboot
Message-Id: <20170206030901.a2ac00bcd93e316782a3e...@googlemail.com>
X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi Timothy,

> I have taken much of the feedback received into account, and revised the
> freedom level categories at
> https://www.coreboot.org/Board_freedom_levels somewhat.  Specifically,
> the "Pwned" category is now factually stated as "Vendor Controlled", and
> the EC exception in the Silver category was removed, among other minor
> tweaks.
> 
> These changes had the effect of demoting all Lenovo laptops to Bronze,
> and promoting the ASUS C201 (Google Veyron) to Gold.  I am still not
> 100% sure that I like the Veyron at Gold status due to the WiFi
> controller, but I will accept it for now pending introduction of
> libre-friendly (firmware-free or HW enforced radio limits with libre
> firmware) WiFi chipsets.
> 
> Comments welcome!

Generally, I like this revised version. Some minor suggestions:

- if you stress the word "require" in the "vendor controlled" section, I would 
suggest to stress the words "require absolutely no" and "require some" in the 
above sections.
- the forecast "No amount of reverse engineering or hacking will ever allow a 
fully libre firmware to execute on these boards." sounds too much like a fact 
and too pesimistic to me to. Although it reflects the current state of what we 
know, I would be careful with making such "absolute" forecasts.
- the term "pwned" is still in the introduction.
- I would mention in the introduction that  this is a classification for 
Coreboot-supported boards, not one for boards in general. This is not really 
clear from the introduction. Therefore, I would also state "All 
coreboot-supported AMD hardware" and so on in the vendor-controlled section.
- the term "libre software operating system" is sort of fuzzy, especially as 
you take into account operating systems which ship kernels that contain 
non-free components (at least the FSF claims that).

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How does SeaBIOS transition to Linux?

[Peter Stuge]

Haleigh Novak wrote:
> I was wondering if anyone could take a few minutes and explain the
> proccess of how coreboots SeaBIOS payload (or even how coreboot
> itself) transitions into a Linux boot sequence to me?

SeaBIOS does nothing coreboot-specific, but uses the de-facto
standard BIOS method: Master Boot Record

In the MBR there is code installed by the bootloader in use
(LILO/NTLDR/GRUB/SYSLINUX/etc)

See wikipedia.org and osdev.org for all MBR details you may want.

Writing a small assembly program to run out of the MBR is a great
exercise.



When coreboot instead starts a Linux kernel directly (with Linux as
payload) then the key word is: SELF

SELF is Simple ELF, and when cbfstool adds a kernel payload to
coreboot.rom it also adds a small stub code at the entry point,
which sets up the data structure in memory which Linux requirs to
boot on x86, before jumping to the kernel entry point.


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Proposal: "Freedom level" field for boards supported by coreboot

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/04/2017 07:50 PM, KOLANICH wrote:
>> No amount of reverse engineering or hacking will ever allow a fully libre 
>> firmware to execute on these boards.
> 
> It's false, hardware can be vulnerable to fault injection attacks allowing to 
> bypass vendor lockin mechanisms.

How exactly does this fault injection mechanism work when the CPU won't
execute a single instruction if an invalid signature is computed?  Every
exploit I am aware of requires one of two things:

* The ability to run arbitrary code in a lower privilege level, then
escalate privilege via bugs in the proprietary software

* The ability to directly control the main CPU through hardware means
(JTAG, DMA attack, etc.)  The needed parts of the hardware are typically
fused off on consumer-bound silicon these days.

Unfortunately for the libre software community, attacking a modern x86
platform in this manner is not only illegal, but has become an arms race
similar to smartphone jailbreaking.  To make matters worse, the x86
manufacturers have already won this arms race at the firmware level;
even if you could find a fault in the firmware and somehow exploit it,
you still have to run that initial signed firmware blob to even get the
system to start executing instructions.

>> Boards in this class require absolutely no proprietary (closed and/or 
>> signed) firmware to operate.
> imho contradicts to
>>> Microcode may be required by the host CPU, and is closed source and/or 
>>> unable to be modified without vendor intervention.
> 
> because microcode is run on main CPU and IMHO is also a firmware

As soon as we can feasibly drop the microcode exemption I will support
its removal.  That being said, only having low-power ARM systems
available is *not* the way to make people care about freedom level;
horizontal microcode has been traditionally exempted for a couple of
decades now, and I see no reason to change this until POWER becomes
somewhat more affordable / common.

>> Boards in this class require proprietary, closed firmware executing on the 
>> main CPU to operate.
> 
> ME is not main CPU, right?
> 
> And I think we need 2 more categories: "explicitly malicious" ("shrinkwrap 
> eula", "DRM", "business aggreement" etc) and "wannabe free" (gold + some 
> hardware is open (firmwares + schematics)  + building open platform is a one 
> of the goals of project).

I disagree.  Any system requiring vendor signing keys at the hardware
level is explicitly malicious, and it does no good whatsoever to make
believe that having open schematics for such a machine is any benefit
whatsoever; it's rather like being able to look at the infrastructure
feeding a factory but still having no idea what's going on inside the
factory.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYl5mjAAoJEK+E3vEXDOFbjIQH/3sIsXKG1GORtGZEPdOsb2eq
kg3D1rmVtKV96qqlSaSDdT3YXwxZ5kP9oH7TRUS7UKiKXygAOjfG9Y36QFZ6PQ1E
c5Pc7cst+0DyRwLTfDcB3Iiv2t16p/gnEPZ455f+J9uuYDLn22CsPO7vZ9k4mNE4
e4fTyGV+okjqLLDNTy0o6VsZogWoWcL7Rf13zffMdnS2nKdy5ShVMke6EJXKkKJA
Gp7/FUdEanVLreT7scyMl2H5d/aS2bSQVkm2X/zTaingM1P6p//Z2oqVLFu32yLv
RpQyLl0Tsj3L//ROU2SRzsc7BN7h3o5JVUI3CVsPPiR7N2/Ang8r6qCLSiVw1Ec=
=h6t7
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Lenovo T420 Question

[Gee Elle]

Hello All,

 I have a question for people running coreboot on T420

Can you please suggest the fastest CPU i can upgrade to without too many heat 
issues ?


i can use more powerful ( 90W  i think ) power brick if needed ..


thank you everyone.


David.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Back to original BIOS

[Zoran Stojsavljevic]

Hello Michael,

Before doing any programming, I have here couple suggestions to you. You
should investigate.

Namely, this: http://thinkwiki.de/UEFI_BIOS_T420_BIOS_Structure

Also, you should look upon the movie here:
https://www.youtube.com/watch?v=DLwaKb6pLrc=player_embedded

Since I am not sure that T420 UEFI BIOS is the same structure as legacy
BIOS T400 has (since I remember that T420 is UEFI, legacy/CSM was on - I
had one at work since 2011 till 2014). But it is worth trying, nothing to
lose.

Knowing that T420 BIOS structure looks like (and I bet it is stored in only
one 8MB flash, as my best bet):

[image: Inline image 1]

You should read your T400 Coreboot flash content, and try to see if it
complies with the given above structure. If it does, you are All Cool.
Namely, you should try to read GbE region, and see where the MAC address
(which you find using Linux command: ifconfig -a). If you appear to find
the spot, you are 100% sure you are All Good, since then you'll read
another BIOS content, and after you will have lot of possibilities for
experiments:
[1] You can reprogram the BIOS from original BIOS to your Coreboot flash
rewriting last 0x30 bytes;
[2] You can rewrite original MAC address to another BIOS, and try to boot;
[3] You can compare/combine regions, and see what'll happen?!
[4] You name it!

I have no idea if you tampered with ME... And no idea if ME for each LENOVO
specimen keeps some unique data from/for the platform.

But I am eager to hear/read what did you find investigating about T400
structure, does it looks the same as T420, and et cetera. :-)

You can also read descriptor region, and post it somewhere, so we can peek
into it (I remember, I have somewhere some explanations about some of these
descriptor region data).

Thank you,
Zoran

On Sat, Feb 4, 2017 at 8:41 AM, Michal Widlok 
wrote:

> Zoran, I'm working on this subject now, but I need to do regular work too
> :-).
>
> Seriously I'm in the process of changing my current stationary
> work-horse to two T400 laptops on docking stations. I've just received
> docks (very dirty, noisy fans) and I borrowed my Raspberry programmer
> to a friend. I hope to finish working on hardware this weekend and I
> will be ready to play with bioses when I get Raspberry back. I think
> that the first method would be to "copy" flash from one board to
> another and we will see. I also try to change MAC in original bios,
> maybe this is possible. I will report everything back, hope it will
> help someone.
> Michael Widlok
>
> PS. Sorry for double mail I messed addresses.
>
> On Fri, Feb 3, 2017 at 9:58 PM, Zoran Stojsavljevic
>  wrote:
> > Ron, I do agree, does not seem to be promising. It will add problems down
> > the road, as requirements grow.
> >
> > Zoran
> >
> > On Fri, Feb 3, 2017 at 8:45 PM, ron minnich  wrote:
> >>
> >>
> >>
> >> On Fri, Feb 3, 2017 at 9:45 AM Zoran Stojsavljevic
> >>  wrote:
> >>>
> >>>
> >>>
> >>> Ron, any (practical) example of above described practices? I have in my
> >>> laptops here 6 x 4 GB DIMM modules and 2 x 8GB DIMM modules, all of
> them
> >>> have SPD mounted.
> >>
> >>
> >>
> >> DIMMs are so great but so old school :-)
> >>
> >> on some systems, in flash, there are 4 and 8 element tables which are
> >> indexed by GPIOs .You use the 2 or 3 bits from 2-3 GPIOs to index the
> table
> >> and that's how you get your RAM programming. No SPD. You can see how
> much
> >> room this leaves for problems.
> >>
> >> This is just one simple example.
> >>
> >> ron
> >>
> >
> >
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot