coreboot November 2013

coreboot@coreboot.org

53 participants
117 discussions

Re: [coreboot] BadBIOS Thoughts
by Gregg Levine 03 Nov '13

03 Nov '13

Hello! I don't know about you Alex, Ron that's a different question, but I, myself, do use WiFi cards, this computer has one, USB sticks, only ones I own, and SATA disks, of course. Both this computer use one, and the one running Linux does. I'm still waiting for a satisfactory response in general to what did happen over there. One of the government agencies have a say, "Trust but verify.". No I don't recall which one, but it is very appropriate. ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again." On Sun, Nov 3, 2013 at 3:49 PM, ron minnich <rminnich(a)gmail.com> wrote: > On Sun, Nov 3, 2013 at 2:47 PM, Alex <mr.nuke.me(a)gmail.com> wrote: > \ >> I'm sorry Ron, but you're just asking me to take your word for it. I can't >> do that. There's more secret code running on a Chromebook's firmware than >> there is free code. In fact, I would argue, most code where attack vectors >> could hide is secret. It's a foul's paradise. > > of course, apropos your comment, do you use > - wifi cards > - usb sticks > - sata disks > > because in that case, you'fe a very trusting person :-) > > ron > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

BadBIOS Thoughts
by Eric Sherouse 03 Nov '13

03 Nov '13

Anyone have any thoughts on Ruiu's 'BadBIOS'? http://arstechnica.com/security/2013/10/meet-badbios-the-mysterious-mac-and…

2 2

Re: [coreboot] Re : Re: BadBIOS Thoughts
by ron minnich 02 Nov '13

02 Nov '13

On Sat, Nov 2, 2013 at 3:39 PM, <echelon(a)free.fr> wrote: > <NAIVE> > Why not a AMD system + coreboot?.. > </NAIVE> ?? not naive at all, but you may not be aware that AMD+coreboot have been partners for 10 years. AMD has been great. ron

1 0

Re : Re: BadBIOS Thoughts
by echelon＠free.fr 02 Nov '13

02 Nov '13

<NAIVE> Why not a AMD system + coreboot?.. </NAIVE> Florentin ----- Mail d'origine ----- De: ron minnich <rminnich(a)gmail.com> À: Gregg Levine <gregg.drwho8(a)gmail.com> Cc: coreboot <coreboot(a)coreboot.org> Envoyé: Sat, 02 Nov 2013 19:57:26 +0100 (CET) Objet: Re: [coreboot] BadBIOS Thoughts I suspect people are learning how to exploit EFI's immense attack surface. Unless it's a successful exploit of the ME, known to be achieved more than once already. The entire PC ecosystem is a giant accident waiting to happen. I'm always surprised to find that people install Linux so they can "have control" of the system. Changing the kernel no longer gets you the amount of control it once did. If they knew how little control they have they'd really be upset. It's not 1999 any more. It's 2013 and the kernel is walled in by constantly running code on the same or other processors (there are at least 4 other OSes running on the average PC nowadays, all capable of doing bad things) that provide it an illusion of control but not complete control. If you really want a system you can trust a bit more, get a Chromebook. The amount of work done in Chromebooks to protect it is extensive and extends beyond the 386 firmware to the ME and the EC and even aspects of the IO devices. ron -- coreboot mailing list: coreboot(a)coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] BadBIOS Thoughts
by ron minnich 02 Nov '13

02 Nov '13

I suspect people are learning how to exploit EFI's immense attack surface. Unless it's a successful exploit of the ME, known to be achieved more than once already. The entire PC ecosystem is a giant accident waiting to happen. I'm always surprised to find that people install Linux so they can "have control" of the system. Changing the kernel no longer gets you the amount of control it once did. If they knew how little control they have they'd really be upset. It's not 1999 any more. It's 2013 and the kernel is walled in by constantly running code on the same or other processors (there are at least 4 other OSes running on the average PC nowadays, all capable of doing bad things) that provide it an illusion of control but not complete control. If you really want a system you can trust a bit more, get a Chromebook. The amount of work done in Chromebooks to protect it is extensive and extends beyond the 386 firmware to the ME and the EC and even aspects of the IO devices. ron

1 0

Install WinXP SP2 Pro with coreboot v4 (no ACPI) and CMOS empty on Abit BF6
by T-800 02 Nov '13

02 Nov '13

Tested on Abit BF6 with coreboot Abit BE6 1. Clear CMOS with jumper on motherboard or remove battery 2. Boot PC from CD WinXP SP2 Pro installation media 2. While 'Press F6' is displayed press F5 3. While 'Press F2' is displayed press F5 one more time 4. Select computer type: Standard PC 5. Set date and time in NVRAM (CMOS): WinXP OS boots and working OK :-)

1 0

Re: [coreboot] Change in coreboot[master]: util/xcompile/xcompile: Remove `-Wno-unused-but-set-variable` from `CFLAGS`
by Paul Menzel 02 Nov '13

02 Nov '13

Dear coreboot folks, Am Dienstag, den 22.10.2013, 23:35 +0200 schrieb gerrit code review: > From Paul Menzel <paulepanter(a)users.sourceforge.net>: > > Paul Menzel has posted comments on this change. > > Change subject: util/xcompile/xcompile: Remove `-Wno-unused-but-set-variable` from `CFLAGS` > ...................................................................... #### > Do not disable warnings about unused but set variables to further > improve the code quality. #### > Patch Set 1: > > Denis, in my opinion the code can always be structured to avoid such > cluttering. Most of the time only a new function has to be added and > in your example the error could be printed in `func2` for example. > > Ron, as can be seen in [1] it is an improvement. Even if it just adds > clarity. > > All in all, I would like to require new boards going into the tree to > have no warnings at all. Maybe a Kconfig option for the old boards > would be smart as some of the cleanup for the old boards is probably > not worth it. > > [1] http://review.coreboot.org/#/c/3985/ looking at the build errors, there are quite a few. And of course most of them in AGESA in `src/vendorcode`. As written above, having this warning is nice to have as it finds errors. Thinking about it, warnings as errors has to be disabled again for AGESA until we figure out, how to deal with those. For the unused but set variables in coreboot “own” code, I’ll send patches. Help is very much appreciated. Thanks, Paul

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