coreboot December 2013

coreboot@coreboot.org

40 participants
108 discussions

Coreboot and the NSA's expressed preference for subverting BIOSes
by David Collier-Brown 31 Dec '13

31 Dec '13

As proposed by Der Spiegel at http://www.spiegel.de/international/world/catalog-reveals-nsa-has-back-door… the NSA seems to be interested in subverting BIOSes, lower-level disk roms and the like. May I request you loudly announce how one checksums one's coreboot, and in principle other BIOSes, so that one can see if anyone has changed firmware critical to one's security. --dave -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb(a)spamcop.net | -- Mark Twain (416) 223-8968

2 1

Re: [coreboot] Inconsistent low-level arch functions between ARM and x86
by David Hendricks 30 Dec '13

30 Dec '13

On Dec 29, 2013 7:17 PM, "ron minnich" <rminnich(a)gmail.com> wrote: > > The functions are wrong in two ways. > > on the x86 side, the addr should be a void *. Had we done this long > ago we would have caught some bugs. > > On the ARM side, the addr should be first, not last, to be consistent > with other "addr"s in coreboot (e.g. pci space). So we'd like to fix > the argument order being backwards too. Yep. I think we had caught this a while back, but left it as-is to be consistent with the u-boot macros. But since we've corrected a few things along the way, such as giving them explicit sizes and doing type checking, I suppose we may as well fix the argument ordering to be consistent with the rest of coreboot. > > It's been on my fix it list for months, it's pretty easy with > coccinnelle, I just have not had time. > > ron > > On Sun, Dec 29, 2013 at 5:16 PM, mrnuke <mr.nuke.me(a)gmail.com> wrote: > > So, I found this: > > > > ARM: static inline void write32(uint32_t val, void *addr) > > x86: static inline void write32(unsigned long addr, uint32_t value) > > > > Now, isn't a 4-byte memory write a 4-byte memory write independent of > > architecture? Forget about the fact that the x86 version takes an unsigned > > long instead of a void * for the address; the ARM and x86 variants have their > > arguments mixed up. > > > > I actually came across this when trying to use our 8250 memmapped UART code on > > an ARM chip. The original code was written for x86, and hence, it can't work > > on ARM (yet). > > > > I propose that these simple memory accessors be unified. Since they refer to a > > memory address, I propose void * for the address parameter. I don't care what > > order the parameters come in as long it's consistent between arches. Any > > takers? > > > > > > Alex > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > http://www.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Inconsistent low-level arch functions between ARM and x86
by mrnuke 30 Dec '13

30 Dec '13

So, I found this: ARM: static inline void write32(uint32_t val, void *addr) x86: static inline void write32(unsigned long addr, uint32_t value) Now, isn't a 4-byte memory write a 4-byte memory write independent of architecture? Forget about the fact that the x86 version takes an unsigned long instead of a void * for the address; the ARM and x86 variants have their arguments mixed up. I actually came across this when trying to use our 8250 memmapped UART code on an ARM chip. The original code was written for x86, and hence, it can't work on ARM (yet). I propose that these simple memory accessors be unified. Since they refer to a memory address, I propose void * for the address parameter. I don't care what order the parameters come in as long it's consistent between arches. Any takers? Alex

2 1

Support for DP35DP
by Leonardo Amaral 29 Dec '13

29 Dec '13

Infos (As FAQ asks): http://pastie.org/pastes/8585115/text Is possible to use/compile Coreboot for it? Leonardo S. Amaral - Computational Physics Undergraduating at Instituto de Física de São Carlos (Institute of Physics at São Carlos - University of São Paulo) - IFSC/USP - NOC Operator at SCW Telecom - Linux System Administrator LPI ID: LPI000106747 Level 2 certified (Verifier hgwxf77vau) Novell Certified Linux Administrator (Novell CLA) SUSE Linux Enterprise 11 ID: 10110565 - Tel: +55 11 94916-0254 (TIM) // +55 16 8856-1250 (Oi)

1 0

Re: [coreboot] Are any Chromebooks able to run fully libre?
by Alex G. 28 Dec '13

28 Dec '13

On 12/24/2013 07:31 PM, Gregg Levine wrote: > Hello! > He's complaining about a missing memo regarding Coreboot and such like. > [...] >>> I must have missed the memo about no coreboot. >> >> Fancy unpacking that statement for those of us who prefer less cryptic >> expression? :) Guys! This is getting ridiculous. Somebody forgot to tell me to NOT work on A10 support[1]. [1] http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+t…

6 7

Re: [coreboot] Are any Chromebooks able to run fully libre?
by Alex G. 27 Dec '13

27 Dec '13

On 12/27/2013 01:29 PM, David Hendricks wrote: > Just to clarify a couple things... > > We don't have an infrastructure for block devices, let alone MMC. > > Up until now this has been considered the work of the payload. The > existing ARM platforms supported in coreboot use SPI ROM to store the > firmware. > And I'd really love if this could continue to be the work of the payload. Sadly, when the firmware is stored on a block device (as is the case with the cubieboard) this becomes our job. > > Our ARM support is still wearing diapers. > > In a generic sense, ARM support is working quite well. We've used it on > a few different SoCs already, not just in the Exynos family. Most of > that code is quite simple and portable. > Is any ARM board shipping with coreboot?

1 0

Re: [coreboot] Are any Chromebooks able to run fully libre?
by Olliver Schinagl 27 Dec '13

27 Dec '13

On 21-12-13 00:37, David Hendricks wrote: > > > > On Fri, Dec 20, 2013 at 3:12 PM, ron minnich <rminnich(a)gmail.com > <mailto:rminnich@gmail.com>> wrote: > > To expand on this answer, it's going to be just about impossible, > going forward, to become blob-free on any popular platform. I can go > into more detail if you want to know the particulars, but there's so > many places in our systems containing blobs, far more than in 2000, > and as fast as we seem to stamp them out, new blobs crop up. > > Not possible on any popular ARM products of which I am aware (e.g. > most of chips have a ROM in the CPU mask which is closed and not > replaceable); definitely not an option on anything new from Intel. And > it's really a matter of a tradeoff. The Chromebooks come with blobs, > it is true; but the EC is blob-free. You can get AMD-based laptops, > maybe with coreboot, and they'll come with a closed EC with blobs. The > wonderful work on the X60 and X201 has gone very far, but the EC blob > remains. It's a really hard problem! > > > I think it's important to keep the scope of these blobs in mind. The BL1 > blob used on the Exynos5xxx chips (like on the Samsung XE303C12 > Chromebook), for example, is small (~8K) and mostly exists to just load > the next phase. Contrast that with the multi-megabyte management engine > blob on Intel platforms that runs on its own microcontroller and has > unfettered access to DRAM and networking resources. For the Allwinner based SoC's (A10, A10s, A13, A20 and A23) there is 1 blob (split into two parts) in the ROM. Blob 1 is the bootloader that tries to boot various media (MMC, NAND, SPI-NOR flash) and which is partially dissasembled (asm -> C) so we know pretty much what it does. It is 9k and has no RAM access and as far as we can tell not invoked after u-boot (sorry no coreboot (yet?) :p) takes over. The second bit in the BROM is the 10k so called 'FEL' mode, emergency recovery mode where it has an USB driver for the OTG controller and allows you to upload and execute code via USB. These blobs are burned into the SoC's rom and unchangable, but we have extract them and it is inspectable what it does [1]. As for the rest of the SoC, we have drivers for almost every bit of IP, except the GPS unit, which actually has been removed from the latest versions of the SoC, the GPU, but with Luc's LIMA that's not a big issue for long and finalyl the VPU, which has been largely reverse engineerd and some working Proof of concept code exists. With the Olimex boards that are opensource-hardware, It's hard to find a more open deal then that. Oliver [1] https://github.com/hno/Allwinner-Info/tree/master/BROM > > For ECs, the attack vector to worry about is key logging but at least > that can be mitigated if you can read the EC firmware and verify its > contents like we do on Chromebooks. But of course simply reading the EC > firmware on a typical laptop can be a challenge... > > > At this point it's harder and harder to escape the Blob. It eats you > alive! http://www.youtube.com/watch?v=TdUsyXQ8Wrs > > I think the idea of creating blob-free systems continues to be a > wonderful idea, one that I'd love to see happen some day. > > ron > > -- > coreboot mailing list: coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > http://www.coreboot.org/mailman/listinfo/coreboot > > > > > -- > David Hendricks (dhendrix) > Systems Software Engineer, Google Inc. > >

4 3

How add or fix code for flashrom working on Abit BF6
by Gelip 26 Dec '13

26 Dec '13

Checked by trial and error method that flashrom works when set PCI registers like this: =============================== setpci -s 00:07.0 b0.l=e0000105 or setpci -s 00:07.0 b2.w=e000 or setpci -s 00:07.0 b3.b=e0 also work setpci -s 00:07.0 b2.w=8000 but e0 is from vendor bios. I found this data in PCI config space device 'ISA Bridge' (offset b0) after boot PC on vendor bios like this: lspci -s 00:07.0 -xxx Next compared this data with coreboot bios PCI config space for this device in offset b0. Please help how fix code coreboot to make flashrom working? P.S. Stefan Tauner wrote that this is coreboot code broken, not flashrom --> Link

1 0

Re: [coreboot] Are any Chromebooks able to run fully libre?
by Sam Kuper 25 Dec '13

25 Dec '13

On 25/12/2013, Gregg Levine <gregg.drwho8(a)gmail.com> wrote: > Hello! > He's complaining about a missing memo regarding Coreboot and such like. How (not) helpful! > I believe I missed a memo regarding the whole thread. Can we wrap this > up? It's getting tedious. With all respect, if you don't like it, please either mute the thread in your email client, or update the Coreboot wiki to the point where newcomers to Coreboot can answer questions like these by reading the wiki rather than needing to ask on the mailing list.

1 0

Re: [coreboot] Are any Chromebooks able to run fully libre?
by Gregg Levine 25 Dec '13

25 Dec '13

Hello! He's complaining about a missing memo regarding Coreboot and such like. I believe I missed a memo regarding the whole thread. Can we wrap this up? It's getting tedious. ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again." On Tue, Dec 24, 2013 at 8:15 PM, Sam Kuper <sam.kuper(a)uclmail.net> wrote: > On Dec 24, 2013 11:16 PM, "Alex G." <mr.nuke.me(a)gmail.com> wrote: >> On 12/22/2013 11:45 PM, Olliver Schinagl wrote: >> > It is 9k and has no RAM access and as far as we can tell not invoked >> > after u-boot (sorry no coreboot (yet?) :p) takes over. >> >> I must have missed the memo about no coreboot. > > Fancy unpacking that statement for those of us who prefer less cryptic > expression? :) > > Sam > > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2013