OpenBIOS July 2013

openbios@openbios.org

13 participants
38 discussions

Secure BIOS for voting?
by SAVIOCvs＠aol.com 19 Jul '13

19 Jul '13

I developed a voting system (see _www.SAVIOC.com_ (http://www.SAVIOC.com) ) that uses ordinary old PCs, yet is more transparent and trustworthy than anything else in use today. All software, including the operating system (FreeDOS) boots from a floppy that can be verified by hash code. The PC never uses the hard drive, and doesn't even need one. Trustworthiness comes from people with different interests being able to prevent each other from doing anything fraudulent. I think the only significant potential vulnerability is that someone with physical access to the machines could install a malicious BIOS. Learning about the OpenBIOS project gave me hope of overcoming that vulnerability. (1) Is my hope justified? Can a PC be booted from a floppy that completely replaces the native BIOS in RAM, and then loads FreeDOS? (Can the possibility of a malicious BIOS be made a non-issue?) If all answers are YES, then the remaining very basic questions become important. (2) Roughly how much space on the floppy would be required? (3) What downloads would I need? OpenBIOS AND OpenFirmware AND OpenBOOT? Anything else? (4) How are they downloaded? http://www.openfirmware.info/index.php/Downloads displays a page beginning, "This page has been deleted." All other links that imply the possibility of downloading reach a page headlined, "The page cannot be displayed". Chuck Gaston

4 3

Join list
by SAVIOCvs＠aol.com 15 Jul '13

15 Jul '13

I presume that this will (soon) make me eligible to post questions.

2 1

Fw: OpenBIOS Digest, Vol 99, Issue 5
by Mike 12 Jul '13

12 Jul '13

hmmm ... no dell under laptops at all ----- Forwarded Message ----- >From: "openbios-request(a)openbios.org" <openbios-request(a)openbios.org> >To: openbios(a)openbios.org >Sent: Friday, July 12, 2013 6:00 AM >Subject: OpenBIOS Digest, Vol 99, Issue 5 > > >Send OpenBIOS mailing list submissions to > openbios(a)openbios.org > >To subscribe or unsubscribe via the World Wide Web, visit > http://www.openfirmware.info/mailman/listinfo/openbios >or, via email, send a message with subject or body 'help' to > openbios-request(a)openbios.org > >You can reach the person managing the list at > openbios-owner(a)openbios.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of OpenBIOS digest..." > > >Today's Topics: > > 1. Re: OpenBIOS Support (Artyom Tarasenko) > 2. [commit] r1170 - in trunk/openbios-devel: drivers > include/arch/common (repository service) > 3. [commit] r1171 - trunk/openbios-devel/include/arch/ppc > (repository service) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 11 Jul 2013 14:27:22 +0200 >From: Artyom Tarasenko <atar4qemu(a)gmail.com> >To: The OpenBIOS Mailinglist <openbios(a)openbios.org> >Subject: Re: [OpenBIOS] OpenBIOS Support >Message-ID: > <CACXAS8C6Z=nypfyKSzvWLP8md2fL5pMaD4GbTkSUXUBkZyppcA(a)mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 > >Hi Mike, > >On Wed, Jul 10, 2013 at 6:52 PM, Mike <wmichaeltrout(a)yahoo.com> wrote: >> I'm a newbie on the list, and I'm just wondering about support forums for >> OpenBIOS ... is there an IRC channel that one could get help >> implenting/installing? I have an old Dell d600 I got cheap at a garage sale, >> that doesn't recognise its hdd, cd drive, or usb for booting -- people have >> said that I must have a bad BIOS. Is this machine a good candidate for >> OpenBIOS? > >Probably not. But you can check the list of motherboards supported by >coreboot here: >http://www.coreboot.org/Supported_Motherboards > >HTH, >Artyom > >-- >Regards, >Artyom Tarasenko > >linux/sparc and solaris/sparc under qemu blog: >http://tyom.blogspot.com/search/label/qemu > > > >------------------------------ > >Message: 2 >Date: Thu, 11 Jul 2013 18:49:26 +0200 >From: repository service <svn(a)openbios.org> >To: openbios(a)openbios.org >Subject: [OpenBIOS] [commit] r1170 - in trunk/openbios-devel: drivers > include/arch/common >Message-ID: <E1UxK3a-0004SB-RR(a)ra.coresystems.de> >Content-Type: text/plain; charset=UTF-8 > >Author: agraf >Date: Thu Jul 11 18:49:26 2013 >New Revision: 1170 >URL: http://tracker.coreboot.org/trac/openbios/changeset/1170 > >Log: >Macio: Fetch nvram offset from fw_cfg if available > >We want the hypervisor to tell us where NVRAM lies so that we do not have to >rely on hardcoded addresses for it. > >Introduce a new fw_cfg interface that allows us to receive it at runtime. > >Signed-off-by: Alexander Graf <agraf(a)suse.de> > >Modified: > trunk/openbios-devel/drivers/macio.c > trunk/openbios-devel/include/arch/common/fw_cfg.h > >Modified: trunk/openbios-devel/drivers/macio.c >============================================================================== >--- trunk/openbios-devel/drivers/macio.c Sun Jun 30 05:13:14 2013 (r1169) >+++ trunk/openbios-devel/drivers/macio.c Thu Jul 11 18:49:26 2013 (r1170) >@@ -43,6 +43,30 @@ > return NW_IO_NVRAM_SIZE >> NW_IO_NVRAM_SHIFT; >} > >+static unsigned long macio_nvram_offset(void) >+{ >+ unsigned long r; >+ >+ /* Hypervisor tells us where NVRAM lies */ >+ r = fw_cfg_read_i32(FW_CFG_PPC_NVRAM_ADDR); >+ if (r) >+ return r; >+ >+ /* Fall back to hardcoded addresses */ >+ if (is_oldworld()) >+ return OW_IO_NVRAM_OFFSET; >+ >+ return NW_IO_NVRAM_OFFSET; >+} >+ >+static unsigned long macio_nvram_size(void) >+{ >+ if (is_oldworld()) >+ return OW_IO_NVRAM_SIZE; >+ else >+ return NW_IO_NVRAM_SIZE; >+} >+ >void macio_nvram_init(const char *path, phys_addr_t addr) >{ > phandle_t chosen, aliases; >@@ -51,13 +75,9 @@ > char buf[64]; > unsigned long nvram_size, nvram_offset; > >- if (is_oldworld()) { >- nvram_offset = OW_IO_NVRAM_OFFSET; >- nvram_size = OW_IO_NVRAM_SIZE; >- } else { >- nvram_offset = NW_IO_NVRAM_OFFSET; >- nvram_size = NW_IO_NVRAM_SIZE; >- } >+ nvram_offset = macio_nvram_offset(); >+ nvram_size = macio_nvram_size(); >+ > nvram = (char*)addr + nvram_offset; > snprintf(buf, sizeof(buf), "%s/nvram", path); > nvram_init(buf); > >Modified: trunk/openbios-devel/include/arch/common/fw_cfg.h >============================================================================== >--- trunk/openbios-devel/include/arch/common/fw_cfg.h Sun Jun 30 05:13:14 2013 (r1169) >+++ trunk/openbios-devel/include/arch/common/fw_cfg.h Thu Jul 11 18:49:26 2013 (r1170) >@@ -44,6 +44,7 @@ >#define FW_CFG_PPC_IS_KVM (FW_CFG_ARCH_LOCAL + 0x05) >#define FW_CFG_PPC_KVM_HC (FW_CFG_ARCH_LOCAL + 0x06) >#define FW_CFG_PPC_KVM_PID (FW_CFG_ARCH_LOCAL + 0x07) >+#define FW_CFG_PPC_NVRAM_ADDR (FW_CFG_ARCH_LOCAL + 0x08) > >#define FW_CFG_INVALID 0xffff > > > > >------------------------------ > >Message: 3 >Date: Thu, 11 Jul 2013 18:49:28 +0200 >From: repository service <svn(a)openbios.org> >To: openbios(a)openbios.org >Subject: [OpenBIOS] [commit] r1171 - > trunk/openbios-devel/include/arch/ppc >Message-ID: <E1UxK3c-0004SM-6X(a)ra.coresystems.de> >Content-Type: text/plain; charset=UTF-8 > >Author: agraf >Date: Thu Jul 11 18:49:27 2013 >New Revision: 1171 >URL: http://tracker.coreboot.org/trac/openbios/changeset/1171 > >Log: >PPC: Add kernel header style typedefs > >When compiling OpenBIOS on openSUSE 12.3 ppc64 I end up getting real host >headers included that make use of the __uxx and __sxx types. > >Define those too in our asm copy of the types.h file, as that one overrides >the host's types.h that we would've used otherwise. > >Signed-off-by: Alexander Graf <agraf(a)suse.de> > >Modified: > trunk/openbios-devel/include/arch/ppc/types.h > >Modified: trunk/openbios-devel/include/arch/ppc/types.h >============================================================================== >--- trunk/openbios-devel/include/arch/ppc/types.h Thu Jul 11 18:49:26 2013 (r1170) >+++ trunk/openbios-devel/include/arch/ppc/types.h Thu Jul 11 18:49:27 2013 (r1171) >@@ -82,13 +82,21 @@ >/* size named types */ > >typedef unsigned char u8; >+typedef unsigned char __u8; >typedef unsigned short u16; >+typedef unsigned short __u16; >typedef unsigned int u32; >+typedef unsigned int __u32; >typedef unsigned long long u64; >+typedef unsigned long long __u64; > >typedef signed char s8; >+typedef signed char __s8; >typedef short s16; >+typedef short __s16; >typedef int s32; >+typedef int __s32; >typedef long long s64; >+typedef long long __s64; > >#endif > > > >------------------------------ > >-- >OpenBIOS mailing list >OpenBIOS(a)openbios.org >http://www.openfirmware.info/mailman/listinfo/openbios > >End of OpenBIOS Digest, Vol 99, Issue 5 >*************************************** > > >

1 0

[commit] r1171 - trunk/openbios-devel/include/arch/ppc
by repository service 11 Jul '13

11 Jul '13

Author: agraf Date: Thu Jul 11 18:49:27 2013 New Revision: 1171 URL: http://tracker.coreboot.org/trac/openbios/changeset/1171 Log: PPC: Add kernel header style typedefs When compiling OpenBIOS on openSUSE 12.3 ppc64 I end up getting real host headers included that make use of the __uxx and __sxx types. Define those too in our asm copy of the types.h file, as that one overrides the host's types.h that we would've used otherwise. Signed-off-by: Alexander Graf <agraf(a)suse.de> Modified: trunk/openbios-devel/include/arch/ppc/types.h Modified: trunk/openbios-devel/include/arch/ppc/types.h ============================================================================== --- trunk/openbios-devel/include/arch/ppc/types.h Thu Jul 11 18:49:26 2013 (r1170) +++ trunk/openbios-devel/include/arch/ppc/types.h Thu Jul 11 18:49:27 2013 (r1171) @@ -82,13 +82,21 @@ /* size named types */ typedef unsigned char u8; +typedef unsigned char __u8; typedef unsigned short u16; +typedef unsigned short __u16; typedef unsigned int u32; +typedef unsigned int __u32; typedef unsigned long long u64; +typedef unsigned long long __u64; typedef signed char s8; +typedef signed char __s8; typedef short s16; +typedef short __s16; typedef int s32; +typedef int __s32; typedef long long s64; +typedef long long __s64; #endif

1 0

[commit] r1170 - in trunk/openbios-devel: drivers include/arch/common
by repository service 11 Jul '13

11 Jul '13

Author: agraf Date: Thu Jul 11 18:49:26 2013 New Revision: 1170 URL: http://tracker.coreboot.org/trac/openbios/changeset/1170 Log: Macio: Fetch nvram offset from fw_cfg if available We want the hypervisor to tell us where NVRAM lies so that we do not have to rely on hardcoded addresses for it. Introduce a new fw_cfg interface that allows us to receive it at runtime. Signed-off-by: Alexander Graf <agraf(a)suse.de> Modified: trunk/openbios-devel/drivers/macio.c trunk/openbios-devel/include/arch/common/fw_cfg.h Modified: trunk/openbios-devel/drivers/macio.c ============================================================================== --- trunk/openbios-devel/drivers/macio.c Sun Jun 30 05:13:14 2013 (r1169) +++ trunk/openbios-devel/drivers/macio.c Thu Jul 11 18:49:26 2013 (r1170) @@ -43,6 +43,30 @@ return NW_IO_NVRAM_SIZE >> NW_IO_NVRAM_SHIFT; } +static unsigned long macio_nvram_offset(void) +{ + unsigned long r; + + /* Hypervisor tells us where NVRAM lies */ + r = fw_cfg_read_i32(FW_CFG_PPC_NVRAM_ADDR); + if (r) + return r; + + /* Fall back to hardcoded addresses */ + if (is_oldworld()) + return OW_IO_NVRAM_OFFSET; + + return NW_IO_NVRAM_OFFSET; +} + +static unsigned long macio_nvram_size(void) +{ + if (is_oldworld()) + return OW_IO_NVRAM_SIZE; + else + return NW_IO_NVRAM_SIZE; +} + void macio_nvram_init(const char *path, phys_addr_t addr) { phandle_t chosen, aliases; @@ -51,13 +75,9 @@ char buf[64]; unsigned long nvram_size, nvram_offset; - if (is_oldworld()) { - nvram_offset = OW_IO_NVRAM_OFFSET; - nvram_size = OW_IO_NVRAM_SIZE; - } else { - nvram_offset = NW_IO_NVRAM_OFFSET; - nvram_size = NW_IO_NVRAM_SIZE; - } + nvram_offset = macio_nvram_offset(); + nvram_size = macio_nvram_size(); + nvram = (char*)addr + nvram_offset; snprintf(buf, sizeof(buf), "%s/nvram", path); nvram_init(buf); Modified: trunk/openbios-devel/include/arch/common/fw_cfg.h ============================================================================== --- trunk/openbios-devel/include/arch/common/fw_cfg.h Sun Jun 30 05:13:14 2013 (r1169) +++ trunk/openbios-devel/include/arch/common/fw_cfg.h Thu Jul 11 18:49:26 2013 (r1170) @@ -44,6 +44,7 @@ #define FW_CFG_PPC_IS_KVM (FW_CFG_ARCH_LOCAL + 0x05) #define FW_CFG_PPC_KVM_HC (FW_CFG_ARCH_LOCAL + 0x06) #define FW_CFG_PPC_KVM_PID (FW_CFG_ARCH_LOCAL + 0x07) +#define FW_CFG_PPC_NVRAM_ADDR (FW_CFG_ARCH_LOCAL + 0x08) #define FW_CFG_INVALID 0xffff

1 0

OpenBIOS Support
by Mike 11 Jul '13

11 Jul '13

I'm a newbie on the list, and I'm just wondering about support forums for OpenBIOS ... is there an IRC channel that one could get help implenting/installing? I have an old Dell d600 I got cheap at a garage sale, that doesn't recognise its hdd, cd drive, or usb for booting -- people have said that I must have a bad BIOS. Is this machine a good candidate for OpenBIOS? And is there a live support forum for a noob to get some assistance?

2 1

Re: [OpenBIOS] [Qemu-devel] [Qemu-ppc] Mac OS X on QEMU
by Programmingkid 11 Jul '13

11 Jul '13

On Jul 4, 2013, at 10:51 AM, Stefan Hajnoczi wrote: > On Thu, Jul 4, 2013 at 4:45 PM, Alexander Graf <agraf(a)suse.de> wrote: >> >> On 04.07.2013, at 16:40, Programmingkid wrote: >> >>> We have made a lot of progress in the last month with making Mac OS X run in QEMU. A lot of people are to thank for this milestone. To everyone involved, thank you. >>> >>> There is one thing that we have to figure out. That is the command key issue. This key is a very important on the Macintosh. It is used to send keyboard shortcuts to applications. >>> >>> What I propose is adding a menu item to QEMU's menu called "Map Command key to ALT". This would allow a user to be able to send Macintosh applications command key shortcuts from both a PC and Mac keyboard. >>> >>> I welcome any and all ideas to solve this problem. >> >> This is the wrong mailing list for this. Your proposal would touch non-PPC code in QEMU, so this needs to go to qemu-devel. >> >> Keep in mind that the same thing arises with x86 Mac OS X running in QEMU. > > When I VNC into a Mac I find that the "Windows key" becomes the > Command key. And the same probably happens when you plug a non-Apple > USB keyboard into a Mac. I was thinking about the Windows key. It would be the perfect substitute - if it was available on all keyboards. > > If you are using a keyboard with a "Windows key" then that would be > the most natural option. If you don't have that key then you really > need to map something else... > > Stefan Maybe there should be two menu items: "Map command key to ALT" and "Map command key to Windows key". They would be mutually exclusive of course.

5 13

Mac OS X on QEMU
by Programmingkid 04 Jul '13

04 Jul '13

We have made a lot of progress in the last month with making Mac OS X run in QEMU. A lot of people are to thank for this milestone. To everyone involved, thank you. There is one thing that we have to figure out. That is the command key issue. This key is a very important on the Macintosh. It is used to send keyboard shortcuts to applications. What I propose is adding a menu item to QEMU's menu called "Map Command key to ALT". This would allow a user to be able to send Macintosh applications command key shortcuts from both a PC and Mac keyboard. I welcome any and all ideas to solve this problem.

4 4