coreboot February 2017

coreboot@coreboot.org

66 participants
212 discussions

Re: [coreboot] Proposal: "Freedom level" field for boards
by Daniel Kulesz 06 Feb '17

06 Feb '17

supported by coreboot Message-Id: <20170206030901.a2ac00bcd93e316782a3e7c0(a)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

2 1

Re: [coreboot] Proposal: "Freedom level" field for boards supported by coreboot
by Timothy Pearson 05 Feb '17

05 Feb '17

-----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-----

1 0

Lenovo T420 Question
by Gee Elle 05 Feb '17

05 Feb '17

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.

1 0

Re: [coreboot] Back to original BIOS
by Zoran Stojsavljevic 05 Feb '17

05 Feb '17

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&feature=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 0x300000 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 <michalwd1979(a)gmail.com> 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 > <zoran.stojsavljevic(a)gmail.com> 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 <rminnich(a)gmail.com> wrote: > >> > >> > >> > >> On Fri, Feb 3, 2017 at 9:45 AM Zoran Stojsavljevic > >> <zoran.stojsavljevic(a)gmail.com> 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(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Proposal: "Freedom level" field for boards supported by coreboot
by Timothy Pearson 04 Feb '17

04 Feb '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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! - -- 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/ iQEcBAEBAgAGBQJYllm2AAoJEK+E3vEXDOFbdpQH/i8hlcTdux/mnDkeD7xVWK4a 7krT2Lft6J7Uf7+9DFLSSh7cINyF9UJyhxuKGcEaSSac9o0gCSrduUKL95JU9MNg ePvZaePiQm9YMgf5SuX6vT2TOSX1NOxJMyFFjsyvwhAnODS8U+HmZR9w/NLdEL1w ApCnP2FQfsnmOAoif7v6b0v3JdzjKT1QauppjIiMBJuze+cMBBXqhUk1A11URy+N GDSk7XPKiVsb/6ryte1767segRXRGR2x5kp6HoH8rRx3NVOunHPKFGH61Grl5vPs 6UYcdRjbpJoV7AsUIsyKBHzsFKGVCyX9tvD09ydRUJjWQJWt6rocDl6bcg8Rwgg= =GWBg -----END PGP SIGNATURE-----

1 0

ASUS KGPE-D16 Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 04 Feb '17

04 Feb '17

The ASUS KGPE-D16 fails verification for branch master as of commit 8a06cc7ec8094325b9f710870f646d2a5cb9eb22 The following tests failed: BOOT_FAILURE Commits since last successful test: 8a06cc7 util/ifdtool: Fix ICH Gbe unlock 4a282b8 mainboard/google/snappy: Set PL2 override to 15000mW 84e6881 mb/lenovo/x60,t60: Move EC CMOS parameters in checksummed space 31db6f5 asus/f2a85-m_le: Activate IOMMU support 3236f7b ectool: Support OpenBSD See attached log for details This message was automatically generated from Raptor Engineering's ASUS KGPE-D16 test stand Want to test on your own equipment? Check out https://www.raptorengineering.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineering.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineering.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] Back to original BIOS
by Michal Widlok 04 Feb '17

04 Feb '17

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 <zoran.stojsavljevic(a)gmail.com> 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 <rminnich(a)gmail.com> wrote: >> >> >> >> On Fri, Feb 3, 2017 at 9:45 AM Zoran Stojsavljevic >> <zoran.stojsavljevic(a)gmail.com> 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 >> > >

1 0

Re: [coreboot] Back to original BIOS
by Zoran Stojsavljevic 03 Feb '17

03 Feb '17

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 <rminnich(a)gmail.com> wrote: > > > On Fri, Feb 3, 2017 at 9:45 AM Zoran Stojsavljevic < > zoran.stojsavljevic(a)gmail.com> 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 > >

1 0

Re: [coreboot] Back to original BIOS
by ron minnich 03 Feb '17

03 Feb '17

On Fri, Feb 3, 2017 at 9:45 AM Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> 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

1 0

Re: [coreboot] Back to original BIOS
by Zoran Stojsavljevic 03 Feb '17

03 Feb '17

> Given the way vendors swap parts around, it would not be surprising to find settings such as GPIOs that control mainboard > resources and DRAM timing in flash. There's lots of ways to save some money nowadays (e.g. remove SPD) and vendors > do what they can to save it all. 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. > There are also flash chips with original T400 bios on sale - what about this? Just waiting for you, Michael, to try it. All the possibilities we lamented here, you got/have several proposals to try practically, and I see it as very good learning experience, and understand more. I offered you one SW method to try, you have original T400 boards with original BIOSes, you can even buy flash chip with original BIOS (and you can also try to combine proposals, also experiment). Several possibilities, one full 10 hours' day of hard work (maybe two days, if you take it easy). And, Enrico (although email is signed as Florian ?!) also wrote an excellent email, with some very good explanation how BIOS descriptors and regions look alike in T420 (I bet, it could be very useful). Being you, I would roll up sleeves and start working... Trying various proposals practically/empirically! My two cent opinion! Peace. ;-) Best Regards, Zoran _______ On Fri, Feb 3, 2017 at 3:15 PM, ron minnich <rminnich(a)gmail.com> wrote: > Given the way vendors swap parts around, it would not be surprising to > find settings such as GPIOs that control mainboard resources and DRAM > timing in flash. There's lots of ways to save some money nowadays (e.g. > remove SPD) and vendors do what they can to save it all. > > ron > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

← Newer
1
...
15
16
17
18
19
20
21
22
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot February 2017