SeaBIOS January 2016

seabios@seabios.org

27 participants
50 discussions

Re: [SeaBIOS] [RFC PATCH v1 0/9] Add TPM 2 support
by Jarkko Sakkinen 23 Jan '16

23 Jan '16

On Fri, Jan 22, 2016 at 03:27:28PM -0500, Stefan Berger wrote: > "Kevin O'Connor" <kevin(a)koconnor.net> wrote on 01/21/2016 05:37:29 PM: > > > > > On Fri, Jan 15, 2016 at 02:44:30PM -0500, Stefan Berger wrote: > > > This series of patches adds TPM 2 support to SeaBIOS in the way previously > > > proposed. > > > > > > TPM 2 support also changes the log entry format, which I have not addressed > > > at all so far, and would append to the end of the series. > > > > Thanks Stefan. In general it looks good to me. I have a few > > comments, which I'll send separately. All of my comments could be > > addressed after committing this series if desired. > > I can address those comments and repost a V2 with the 10th patch adding the > part for the logging. > > > > > How does one test and/or use this support? Does QEMU have support, or > > is there hardware available on coreboot with the tpm2 hardware? > > I did all the testing of these patches with the vTPM with CUSE interface > integrated into QEMU. Unfortunately the vTPM-QEMU integration train seems a > wreck now following comments on QEMU mailing list. So, I don't know of any TPM > 2 hardware out there, less so hardware where coreboot runs. So that's probably > currently the number one problem. > > You know the TPM 1.2 PC BIOS specification, right? I think we can say that many > of the functions implemented in this series for TPM 2 are necessary because of > how it's done for TPM 1.2 as well as properties of the TPM 2 device. This > includes the TPM initialization, S3 support, setting of timeouts, menu items, > etc. The problem with TPM 2 is that there's no official spec for TPM 2 for a > BIOS. So it's not quite clear to me how much leeway we have to go about this in > the areas of ACPI tables for logging and the API. Regarding these topics: > > ACPI tables for logging: The (U)EFI specification for TPM 2 don't require a > TCPA table with the logging area because there seems to be an API for the OS > for retrieving the log. UEFI seems to log into just some buffer, not connected > to any ACPI table. For the BIOS we would still need that TCPA table. QEMU > currently provides that. The Linux kernel (and all other OSes -- uuuh) would > then have to allow a TCPA table for logging for TPM 2 even though we cannot > point to a spec for that. Not sure whether we can create a standard for this > little gap here... Do you know the reason why it isn't required? This really confuses me that there isn't anything standardized for TPM2. How can that have happened... /Jarkko > BIOS API: Some functions pass the entry to write into the log via the function > directly. Patch 10 handles that and transforms that entry into the log entry > format as required for TPM 1.2 or TPM 2 (log entries are differently formatted > for TPM 1.2 and for TPM 2). So the only remaining problem I know of is the > function that allows one to pass TPM commands through to the TPM. This may end > up causing problems in the application if it was written for TPM 1.2 and now > there's a TPM 2 running underneath, which doesn't understand the TPM 1.2 > commands. I would say this is likely the smaller of the problems also > considering that there are not many applications out there that use that API > call. Possibility to just shut down that function call is certainly there. > > Stefan > > > > > > -Kevin > > >

1 0

Qemu/Seabios and loading option roms
by Bob Moore 23 Jan '16

23 Jan '16

Hi, I'm new to qemu/seabios and am in the process of developing an option rom for a pcie device. I want to use seabios as a driver for debugging this code. I see documentation that says I can put my option rom into a file with name of the form pciVVVV,DDDD.rom to contain my compiled/linked code that will be used when the device having that VendorID/DeviceId is processed in init_pcirom(). The lookup_hardcode() call looks for this file on a list via romfile_find(). The list looks to be populated from FW_CFG_FILE_DIR but I can't seem to find where the entries on this list actually come from. Is there a specific directory in the qemu project that is configured to contain these entries? Or maybe these are just configured in a file someplace? Any help would be greatly appreciated. Thanks. Robert (Bob) L Moore Firmware Engineer CIBU Platform o: 719-799-4642 (ext. 244642) robert.moore(a)hgst.com<mailto:robert.moore@hgst.com> [cid:image001.png@01D13689.346E0520] 1975 Research Pkwy, Suite 135 Colorado Springs, CO 80920 www.wdc.com<http://www.wdc.com/> HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system.

1 0

[RFC PATCH v1 0/9] Add TPM 2 support
by Stefan Berger 22 Jan '16

22 Jan '16

This series of patches adds TPM 2 support to SeaBIOS in the way previously proposed. TPM 2 support also changes the log entry format, which I have not addressed at all so far, and would append to the end of the series. Stefan Stefan Berger (9): tpm: Extend TPM TIS with TPM 2 support. tpm: Factor out tpm_extend tpm: Prepare code for TPM 2 functions tpm: Implement tpm2_startup and tpm2_s3_resume tpm: Implement tpm2_set_timeouts tpm: Implement tpm2_prepboot tpm: Implement tpm2_extend tpm: Implement tpm2_menu tpm: Implement TPM 2's set_failure src/hw/tpm_drivers.c | 39 +++ src/hw/tpm_drivers.h | 24 ++ src/std/tcg.h | 110 ++++++++ src/tcgbios.c | 692 ++++++++++++++++++++++++++++++++++++++++++--------- 4 files changed, 749 insertions(+), 116 deletions(-) -- 2.4.3

2 15

SeaBIOS security feature roadmap?
by Blibbet 18 Jan '16

18 Jan '16

Hi, I'm pretty new to the SeaBIOS codebase. I've noticed a lot of interesting TPM-centric checkins recently.I was wondering if there was any roadmap for current/upcoming SeaBIOS security features. I'd be especially interested in any consumer devices that may have this enhanced BIOS security in their devices (or VMs). I haven't found anything on the topic, any pointers appreciated. I think most consider BIOS still consider to be "insecure", so I'd like to be able to note some BIOS security improvements, and where people can find them and use these features. Thanks, Lee RSS: http://firmwaresecurity.com/feed

3 6

Re: [SeaBIOS] [PATCH v2] biostables: Support SMBIOS 2.6+ UUID format
by Kevin O'Connor 18 Jan '16

18 Jan '16

On Fri, Jan 15, 2016 at 10:49:32AM -0500, Cole Robinson wrote: > SMBIOS 2.6+ stores the UUID in a different format, with the first 3 > fields in little endian format. This is what modern qemu delivers > and what dmidecode also handles, so let's follow suit too. Thanks - committed. Gerd, I'm guessing this is a candidate for 1.9.1 too. -Kevin

2 1

[PATCH 0/2] Improve reboot races during post and reboot
by Kevin O'Connor 18 Jan '16

18 Jan '16

This is a follow up to an email chain that in November: http://www.seabios.org/pipermail/seabios/2015-November/009887.html It was possible for the SeaBIOS code to get confused if an external reboot request occurs while seabios is already in the process of handling a boot or reboot. This two patch series attempts to make the SeaBIOS reboot code more robust. With these patches the code maintains an invariant - if HaveRunPost is false then the BIOS code will be in a pristine state and it is okay to run the "post" boot logic; if HaveRunPost is true then the reboot logic must be run before starting the "post" boot logic. The reboot handler should always return the BIOS code to a pristine state prior to clearing HaveRunPost. -Kevin Kevin O'Connor (2): resume: Make KVM soft reboot loop detection more flexible post: Always set HaveRunPost prior to setting any other global variable src/fw/csm.c | 1 + src/fw/shadow.c | 17 +++++++++++++++-- src/fw/xen.c | 1 + src/post.c | 20 ++++++++++++++++---- src/resume.c | 9 --------- src/util.h | 1 + 6 files changed, 34 insertions(+), 15 deletions(-) -- 2.5.0

3 5

Very Old Machines
by Eli Duttman 17 Jan '16

17 Jan '16

SeaBIOS seems to be a possibility for the ancient ISA bus machine reactivation project I have begun. What's currently in ROM lacks INT 13H extension support and is not Y2K compliant. When last used in the early 2000s, entering a 2nnn year seemed to be OK. An EEPROM is not present and any "load" would have to burned into 1 or more EPROMs. TIA, for any replies. Eli D.

1 0

[PATCH v2] biostables: Support SMBIOS 2.6+ UUID format
by Cole Robinson 15 Jan '16

15 Jan '16

SMBIOS 2.6+ stores the UUID in a different format, with the first 3 fields in little endian format. This is what modern qemu delivers and what dmidecode also handles, so let's follow suit too. More info at this thread: http://www.seabios.org/pipermail/seabios/2015-November/010031.html The only place this affects is when reporting the UUID at startup. https://bugzilla.redhat.com/show_bug.cgi?id=1284259 Signed-off-by: Cole Robinson <crobinso(a)redhat.com> --- v2: Update the comment src/fw/biostables.c | 47 ++++++++++++++++++++++++++++++++++++----------- 1 file changed, 36 insertions(+), 11 deletions(-) diff --git a/src/fw/biostables.c b/src/fw/biostables.c index cb74396..9fb9ff9 100644 --- a/src/fw/biostables.c +++ b/src/fw/biostables.c @@ -306,17 +306,42 @@ display_uuid(void) if (memcmp(uuid, empty_uuid, sizeof(empty_uuid)) == 0) return; - printf("Machine UUID" - " %02x%02x%02x%02x" - "-%02x%02x" - "-%02x%02x" - "-%02x%02x" - "-%02x%02x%02x%02x%02x%02x\n" - , uuid[ 0], uuid[ 1], uuid[ 2], uuid[ 3] - , uuid[ 4], uuid[ 5] - , uuid[ 6], uuid[ 7] - , uuid[ 8], uuid[ 9] - , uuid[10], uuid[11], uuid[12], uuid[13], uuid[14], uuid[15]); + /* + * According to SMBIOS v2.6 the first three fields are encoded in + * little-endian format. Versions prior to v2.6 did not specify + * the encoding, but we follow dmidecode and assume big-endian + * encoding. + */ + if (SMBiosAddr->smbios_major_version > 2 || + (SMBiosAddr->smbios_major_version == 2 && + SMBiosAddr->smbios_minor_version >= 6)) { + printf("Machine UUID" + " %02x%02x%02x%02x" + "-%02x%02x" + "-%02x%02x" + "-%02x%02x" + "-%02x%02x%02x%02x%02x%02x\n" + , uuid[ 3], uuid[ 2], uuid[ 1], uuid[ 0] + , uuid[ 5], uuid[ 4] + , uuid[ 7], uuid[ 6] + , uuid[ 8], uuid[ 9] + , uuid[10], uuid[11], uuid[12] + , uuid[13], uuid[14], uuid[15]); + } else { + printf("Machine UUID" + " %02x%02x%02x%02x" + "-%02x%02x" + "-%02x%02x" + "-%02x%02x" + "-%02x%02x%02x%02x%02x%02x\n" + , uuid[ 0], uuid[ 1], uuid[ 2], uuid[ 3] + , uuid[ 4], uuid[ 5] + , uuid[ 6], uuid[ 7] + , uuid[ 8], uuid[ 9] + , uuid[10], uuid[11], uuid[12] + , uuid[13], uuid[14], uuid[15]); + } + return; } } -- 2.5.0

1 0

[PATCH 1/2] kbd: Don't treat scancode and asciicode as separate values
by Kevin O'Connor 15 Jan '16

15 Jan '16

The scancode/asciicode pair can be more easily handled as a single 16bit value. Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/kbd.c | 53 +++++++++++++++++++++-------------------------------- 1 file changed, 21 insertions(+), 32 deletions(-) diff --git a/src/kbd.c b/src/kbd.c index a5a1ad9..2bf7398 100644 --- a/src/kbd.c +++ b/src/kbd.c @@ -52,7 +52,7 @@ kbd_init(void) } static u8 -enqueue_key(u8 scan_code, u8 ascii_code) +enqueue_key(u16 keycode) { u16 buffer_start = GET_BDA(kbd_buf_start_offset); u16 buffer_end = GET_BDA(kbd_buf_end_offset); @@ -68,8 +68,7 @@ enqueue_key(u8 scan_code, u8 ascii_code) if (buffer_tail == buffer_head) return 0; - SET_FARVAR(SEG_BDA, *(u8*)(temp_tail+0), ascii_code); - SET_FARVAR(SEG_BDA, *(u8*)(temp_tail+1), scan_code); + SET_FARVAR(SEG_BDA, *(u16*)(temp_tail+0), keycode); SET_BDA(kbd_buf_tail, buffer_tail); return 1; } @@ -147,7 +146,7 @@ handle_1602(struct bregs *regs) static void handle_1605(struct bregs *regs) { - regs->al = !enqueue_key(regs->ch, regs->cl); + regs->al = !enqueue_key(regs->cx); } // GET KEYBOARD FUNCTIONALITY @@ -289,7 +288,7 @@ static struct scaninfo { u16 control; u16 alt; u8 lock_flags; -} scan_to_scanascii[] VAR16 = { +} scan_to_keycode[] VAR16 = { { none, none, none, none, none }, { 0x011b, 0x011b, 0x011b, 0x0100, none }, /* escape */ { 0x0231, 0x0221, none, 0x7800, none }, /* 1! */ @@ -504,48 +503,38 @@ __process_key(u8 scancode) SET_BDA(soft_reset_flag, 0x1234); reset(); } - if (scancode >= ARRAY_SIZE(scan_to_scanascii)) { + if (scancode >= ARRAY_SIZE(scan_to_keycode)) { dprintf(1, "KBD: int09h_handler(): unknown scancode read: 0x%02x!\n" , scancode); return; } - u8 asciicode; - struct scaninfo *info = &scan_to_scanascii[scancode]; + u16 keycode; + struct scaninfo *info = &scan_to_keycode[scancode]; if (flags0 & KF0_ALTACTIVE) { - asciicode = GET_GLOBAL(info->alt); - scancode = GET_GLOBAL(info->alt) >> 8; + keycode = GET_GLOBAL(info->alt); } else if (flags0 & KF0_CTRLACTIVE) { - asciicode = GET_GLOBAL(info->control); - scancode = GET_GLOBAL(info->control) >> 8; + keycode = GET_GLOBAL(info->control); } else if (flags2 & KF2_LAST_E0 && scancode >= 0x47 && scancode <= 0x53) { /* extended keys handling */ - asciicode = 0xe0; - scancode = GET_GLOBAL(info->normal) >> 8; + keycode = (scancode << 8) | 0xe0; } else if (flags0 & (KF0_RSHIFT|KF0_LSHIFT)) { /* check if lock state should be ignored because a SHIFT * key is pressed */ - - if (flags0 & GET_GLOBAL(info->lock_flags)) { - asciicode = GET_GLOBAL(info->normal); - scancode = GET_GLOBAL(info->normal) >> 8; - } else { - asciicode = GET_GLOBAL(info->shift); - scancode = GET_GLOBAL(info->shift) >> 8; - } + if (flags0 & GET_GLOBAL(info->lock_flags)) + keycode = GET_GLOBAL(info->normal); + else + keycode = GET_GLOBAL(info->shift); } else { /* check if lock is on */ - if (flags0 & GET_GLOBAL(info->lock_flags)) { - asciicode = GET_GLOBAL(info->shift); - scancode = GET_GLOBAL(info->shift) >> 8; - } else { - asciicode = GET_GLOBAL(info->normal); - scancode = GET_GLOBAL(info->normal) >> 8; - } + if (flags0 & GET_GLOBAL(info->lock_flags)) + keycode = GET_GLOBAL(info->shift); + else + keycode = GET_GLOBAL(info->normal); } - if (scancode==0 && asciicode==0) - dprintf(1, "KBD: scancode & asciicode are zero?\n"); - enqueue_key(scancode, asciicode); + if (!keycode) + dprintf(1, "KBD: keycode is zero?\n"); + enqueue_key(keycode); break; } flags2 &= ~KF2_LAST_E0; -- 2.5.0

1 2

Re: [SeaBIOS] [PATCH] biostables: Support SMBIOS 2.6+ UUID format
by Kevin O'Connor 15 Jan '16

15 Jan '16

On Tue, Jan 12, 2016 at 02:22:41PM -0500, Cole Robinson wrote: > SMBIOS 2.6+ stores the UUID in a different format, with the first 3 > fields in little endian format. This is what modern qemu delivers > and what dmidecode also handles, so let's follow suit too. More > info at this thread: > > http://www.seabios.org/pipermail/seabios/2015-November/010031.html > > The only place this affects is when reporting the UUID at startup. > > https://bugzilla.redhat.com/show_bug.cgi?id=1284259 > --- > src/fw/biostables.c | 51 ++++++++++++++++++++++++++++++++++++++++----------- > 1 file changed, 40 insertions(+), 11 deletions(-) > > diff --git a/src/fw/biostables.c b/src/fw/biostables.c > index cb74396..2e15f82 100644 > --- a/src/fw/biostables.c > +++ b/src/fw/biostables.c > @@ -306,17 +306,46 @@ display_uuid(void) > if (memcmp(uuid, empty_uuid, sizeof(empty_uuid)) == 0) > return; > > - printf("Machine UUID" > - " %02x%02x%02x%02x" > - "-%02x%02x" > - "-%02x%02x" > - "-%02x%02x" > - "-%02x%02x%02x%02x%02x%02x\n" > - , uuid[ 0], uuid[ 1], uuid[ 2], uuid[ 3] > - , uuid[ 4], uuid[ 5] > - , uuid[ 6], uuid[ 7] > - , uuid[ 8], uuid[ 9] > - , uuid[10], uuid[11], uuid[12], uuid[13], uuid[14], uuid[15]); > + /* > + * comment borrowed from dmidecode: > + * > + * As of version 2.6 of the SMBIOS specification, the first 3 > + * fields of the UUID are supposed to be encoded on little-endian. > + * The specification says that this is the defacto standard, > + * however I've seen systems following RFC 4122 instead and use > + * network byte order, so I am reluctant to apply the byte-swapping > + * for older versions. > + */ I find this comment confusing - how about something like: According to SMBIOS v2.6 the first three fields are encoded in little-endian format. Versions prior to v2.6 did not specify the encoding, but we follow dmidecode and assume big-endian encoding. > + if (SMBiosAddr->smbios_major_version > 2 || > + (SMBiosAddr->smbios_major_version == 2 && > + SMBiosAddr->smbios_minor_version >= 6)) { > + printf("Machine UUID" > + " %02x%02x%02x%02x" > + "-%02x%02x" > + "-%02x%02x" > + "-%02x%02x" > + "-%02x%02x%02x%02x%02x%02x\n" > + , uuid[ 3], uuid[ 2], uuid[ 1], uuid[ 0] > + , uuid[ 5], uuid[ 4] > + , uuid[ 7], uuid[ 6] > + , uuid[ 8], uuid[ 9] > + , uuid[10], uuid[11], uuid[12] > + , uuid[13], uuid[14], uuid[15]); > + } else { > + printf("Machine UUID" > + " %02x%02x%02x%02x" > + "-%02x%02x" > + "-%02x%02x" > + "-%02x%02x" > + "-%02x%02x%02x%02x%02x%02x\n" > + , uuid[ 0], uuid[ 1], uuid[ 2], uuid[ 3] > + , uuid[ 4], uuid[ 5] > + , uuid[ 6], uuid[ 7] > + , uuid[ 8], uuid[ 9] > + , uuid[10], uuid[11], uuid[12] > + , uuid[13], uuid[14], uuid[15]); > + } The above is okay to me, but I'd like to get Gerd's comments as well, as I think he had some concerns the last time it came up. -Kevin

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS January 2016