SeaBIOS

seabios@seabios.org

3783 discussions

Re: [SeaBIOS] [PATCH 0/4] RFC: add CRB TPM device
by Stefan Berger 13 Feb '18

13 Feb '18

On 02/12/2018 01:17 PM, Marc-Andre Lureau wrote: > Hi > > On Sun, Feb 11, 2018 at 5:53 PM, Stefan Berger > <stefanb(a)linux.vnet.ibm.com> wrote: >> On 10/06/2017 10:33 AM, marcandre.lureau(a)redhat.com wrote: >>> From: Marc-André Lureau <marcandre.lureau(a)redhat.com> >>> >>> Hi, >>> >>> The following series implements a limited TPM CRB driver. The TIS >>> device with a TPM 2.0 seems to be ignored by Windows 10, so I >>> implemented a simple CRB device that I will send shortly on the >>> qemu-devel. With the CRB device, Windows 10 correctly recognized and >>> exchange with a TPM 2.0. >>> >>> As long as the device isn't in qemu, I suppose this series should >>> remain RFC. >> >> I think you can repost it now... > Indeed, the device is now in qemu. However, I don't have much time / > priority to work on seabios support for now. Since you have additional > patches on top, and you are experienced with that, perhaps you could > send the whole series including my patches (adding your reviewed-by / > signed-off and some text if you modified my patches)? I suppose that > would work for Kevin too? Fine by me. Stefan

1 0

[PATCH 0/4] RFC: add CRB TPM device
by marcandre.lureau＠redhat.com 13 Feb '18

13 Feb '18

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> Hi, The following series implements a limited TPM CRB driver. The TIS device with a TPM 2.0 seems to be ignored by Windows 10, so I implemented a simple CRB device that I will send shortly on the qemu-devel. With the CRB device, Windows 10 correctly recognized and exchange with a TPM 2.0. As long as the device isn't in qemu, I suppose this series should remain RFC. Feedback welcome! Marc-André Lureau (4): x86: add readq() tpm: generalize init_timeout() tpm: use get_tpm_version() callback WIP: add TPM CRB device support src/hw/tpm_drivers.c | 226 ++++++++++++++++++++++++++++++++++++++++++++++++--- src/hw/tpm_drivers.h | 26 ++++++ src/x86.h | 5 ++ 3 files changed, 245 insertions(+), 12 deletions(-) -- 2.14.1.146.gd35faa819

5 12

[PATCH 1/5] floppy: hold the DOR reset bit low for 4 microseconds, when resetting the floppy controller
by Nikolay Nikolov 10 Feb '18

10 Feb '18

Signed-off-by: Nikolay Nikolov <nickysn(a)users.sourceforge.net> --- src/hw/floppy.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/hw/floppy.c b/src/hw/floppy.c index 3012b3a..16989c2 100644 --- a/src/hw/floppy.c +++ b/src/hw/floppy.c @@ -328,6 +328,8 @@ floppy_enable_controller(void) dprintf(2, "Floppy_enable_controller\n"); // Clear the reset bit (enter reset state), but set 'enable IRQ and DMA' floppy_dor_mask(FLOPPY_DOR_RESET, FLOPPY_DOR_IRQ); + // Real hardware needs a 4 microsecond delay + usleep(4); // Set the reset bit (normal operation) and keep 'enable IRQ and DMA' on floppy_dor_mask(0, FLOPPY_DOR_IRQ | FLOPPY_DOR_RESET); int ret = floppy_wait_irq(); -- 2.14.3

3 7

Re: [SeaBIOS] Saving a few bytes across a reboot
by Stefan Berger 09 Feb '18

09 Feb '18

On 02/08/2018 02:30 PM, Marc-André Lureau wrote: > Hi > > On Thu, Feb 8, 2018 at 5:35 PM, Stefan Berger > <stefanb(a)linux.vnet.ibm.com> wrote: >> On 02/08/2018 10:52 AM, Marc-André Lureau wrote: >>> Hi >>> >>> On Wed, Feb 7, 2018 at 6:21 PM, Laszlo Ersek <lersek(a)redhat.com> wrote: >>>> On 02/07/18 17:44, Stefan Berger wrote: >>>>> On 02/07/2018 10:50 AM, Laszlo Ersek wrote: >>>>>> OK, but if the OS is allowed to modify this set of "queued operations", >>>>>> then what protection is expected of SMM? Whether you can modify the TPM >>>>>> directly, or queue random commands for it at libery, what's the >>>>>> difference? >>>>> >>>>> On the OS level it is presumably an operation that is reserved to the >>>>> admin to queue the operation. >>>>> >>>>> I am not that familiar with UEFI and who is allowed to run code there >>>>> and what code it can execute. But UEFI seems to lock the variable that >>>>> holds that PPI code that tells it what to do after next reboot. So >>>>> presumably a UEFI module cannot modify that variable but can only read >>>>> it (and hopefully not manipulate NVRAM directly). If PPI was implemented >>>>> through a memory location where the code gets written to it could do >>>>> that likely easily (unless memory protections are setup by UEFI, which I >>>>> don't know), cause a reset and have UEFI execute on that code. >>>> This makes sense... but then it doesn't make sense :) >>>> >>>> Assume that the variable is indeed "locked" (so that random UEFI drivers >>>> / apps cannot rewrite it using the UEFI variable service). Then, >>>> >>>> - if the lock is enforced in SMM, then the variable will be locked from >>>> the OS as well, not just from 3rd party UEFI apps, so no PPI >>>> operations can ever be queued, >>>> >>>> - if the lock is "simulated" in ACPI or in non-SMM firmare code (= in >>>> the "runtime DXE driver" layer), then the lock can be circumvented by >>>> both 3rd party UEFI apps and the OS. >>> >>> Regarding security of PPI pending operations, the spec clearly says >>> "The location for tracking the pending PPI >>> operation, including the tracking of necessary PLATFORM RESET >>> operations, does not need to be a secure or trusted location." (9.9 >>> p.32) >>> >>> I assume this is because the user has to confirm the pending operation >>> in pre-os console, so if some attacker wanted to clear the TPM, the >>> user would have to confirm it (same for other operation of flags >>> manipulation). That may not be the best security design, but at least, >>> the user could be in control. >> >> I had not read that - at least not recently. >> There are operations that eliminate the future prompt (operation 18) but >> these require at least a one-time interaction. Though the flag that causes >> the prompt needs to be protected so that some software cannot just modify it >> and cause a clear without user interaction. In UEFI this is solved (hope) >> with the locking of the variable. In a BIOS one could store it in a TPM >> NVRAM location that has access restrictions that can only be fulfilled by >> the firmware. > Or it could be stored in the "PPI qemu device" you proposed, couldn't it? > > The firmware could lock the access to some PPI memory after a PPI phase. > > That may not be as secure as SMM variable lock service in UEFI, but > that would be more portable and probably easier to implement. These particular flags should survive reboot. They are more or less a firmware configuration. Since there's no CMOS we could stick them into the TPM's NVRAM, which has its security advantages. So some malicious software could try to set or clear the flag that would prompt a user for confirmation for clearing the TPM for example. It would have to set this flag in RAM and SeaBIOS would react to that and finally transfer the flag into TPM NVRAM that only the firmware can access while the TPM is in a certain (in particular it would be 'TPMA_NV_PPWRITE' on the NVRAM location). > >>> How does the UEFI runtime variable services verify the authenticity of >>> the requests? Or does it only check a request validity? >> >> Afaics it only checks whether the request has valid parameters, not where it >> comes from. > Then I don't see much point yet going through SMM to set the pending > operations (protecting the result could eventually be good though). > > Not sure except for re-using existing code in EDK2.

1 0

Re: [SeaBIOS] Saving a few bytes across a reboot
by Stefan Berger 09 Feb '18

09 Feb '18

On 02/08/2018 10:52 AM, Marc-André Lureau wrote: > Hi > > On Wed, Feb 7, 2018 at 6:21 PM, Laszlo Ersek <lersek(a)redhat.com> wrote: >> On 02/07/18 17:44, Stefan Berger wrote: >>> On 02/07/2018 10:50 AM, Laszlo Ersek wrote: >>>> OK, but if the OS is allowed to modify this set of "queued operations", >>>> then what protection is expected of SMM? Whether you can modify the TPM >>>> directly, or queue random commands for it at libery, what's the >>>> difference? >>> >>> On the OS level it is presumably an operation that is reserved to the >>> admin to queue the operation. >>> >>> I am not that familiar with UEFI and who is allowed to run code there >>> and what code it can execute. But UEFI seems to lock the variable that >>> holds that PPI code that tells it what to do after next reboot. So >>> presumably a UEFI module cannot modify that variable but can only read >>> it (and hopefully not manipulate NVRAM directly). If PPI was implemented >>> through a memory location where the code gets written to it could do >>> that likely easily (unless memory protections are setup by UEFI, which I >>> don't know), cause a reset and have UEFI execute on that code. >> This makes sense... but then it doesn't make sense :) >> >> Assume that the variable is indeed "locked" (so that random UEFI drivers >> / apps cannot rewrite it using the UEFI variable service). Then, >> >> - if the lock is enforced in SMM, then the variable will be locked from >> the OS as well, not just from 3rd party UEFI apps, so no PPI >> operations can ever be queued, >> >> - if the lock is "simulated" in ACPI or in non-SMM firmare code (= in >> the "runtime DXE driver" layer), then the lock can be circumvented by >> both 3rd party UEFI apps and the OS. > > Regarding security of PPI pending operations, the spec clearly says > "The location for tracking the pending PPI > operation, including the tracking of necessary PLATFORM RESET > operations, does not need to be a secure or trusted location." (9.9 > p.32) > > I assume this is because the user has to confirm the pending operation > in pre-os console, so if some attacker wanted to clear the TPM, the > user would have to confirm it (same for other operation of flags > manipulation). That may not be the best security design, but at least, > the user could be in control. I had not read that - at least not recently. There are operations that eliminate the future prompt (operation 18) but these require at least a one-time interaction. Though the flag that causes the prompt needs to be protected so that some software cannot just modify it and cause a clear without user interaction. In UEFI this is solved (hope) with the locking of the variable. In a BIOS one could store it in a TPM NVRAM location that has access restrictions that can only be fulfilled by the firmware. > > How does the UEFI runtime variable services verify the authenticity of > the requests? Or does it only check a request validity? Afaics it only checks whether the request has valid parameters, not where it comes from. > > thanks >

2 1

[PATCH 1/6] Introduce the floppy_dor_read() function
by Nikolay Nikolov 09 Feb '18

09 Feb '18

Signed-off-by: Nikolay Nikolov <nickysn(a)users.sourceforge.net> --- src/hw/floppy.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/src/hw/floppy.c b/src/hw/floppy.c index f2577c5..9c44a58 100644 --- a/src/hw/floppy.c +++ b/src/hw/floppy.c @@ -180,6 +180,12 @@ find_floppy_type(u32 size) u8 FloppyDOR VARLOW; +static inline u8 +floppy_dor_read(void) +{ + return GET_LOW(FloppyDOR); +} + static inline void floppy_dor_write(u8 val) { @@ -318,7 +324,7 @@ static int floppy_drive_pio(u8 floppyid, int command, u8 *param) { // Enable controller if it isn't running. - if (!(GET_LOW(FloppyDOR) & 0x04)) { + if (!(floppy_dor_read() & 0x04)) { int ret = floppy_enable_controller(); if (ret) return ret; @@ -668,6 +674,6 @@ floppy_tick(void) SET_BDA(floppy_motor_counter, fcount); if (fcount == 0) // turn motor(s) off - floppy_dor_write(GET_LOW(FloppyDOR) & ~0xf0); + floppy_dor_write(floppy_dor_read() & ~0xf0); } } -- 2.14.3

3 10

Re: [SeaBIOS] Saving a few bytes across a reboot
by Laszlo Ersek 09 Feb '18

09 Feb '18

On 02/08/18 16:52, Marc-André Lureau wrote: > Hi > > On Wed, Feb 7, 2018 at 6:21 PM, Laszlo Ersek <lersek(a)redhat.com> > wrote: >> On 02/07/18 17:44, Stefan Berger wrote: >>> On 02/07/2018 10:50 AM, Laszlo Ersek wrote: >> >>>> OK, but if the OS is allowed to modify this set of "queued >>>> operations", then what protection is expected of SMM? Whether you >>>> can modify the TPM directly, or queue random commands for it at >>>> libery, what's the difference? >>> >>> >>> On the OS level it is presumably an operation that is reserved to >>> the admin to queue the operation. >>> >>> I am not that familiar with UEFI and who is allowed to run code >>> there and what code it can execute. But UEFI seems to lock the >>> variable that holds that PPI code that tells it what to do after >>> next reboot. So presumably a UEFI module cannot modify that variable >>> but can only read it (and hopefully not manipulate NVRAM directly). >>> If PPI was implemented through a memory location where the code gets >>> written to it could do that likely easily (unless memory protections >>> are setup by UEFI, which I don't know), cause a reset and have UEFI >>> execute on that code. >> >> This makes sense... but then it doesn't make sense :) >> >> Assume that the variable is indeed "locked" (so that random UEFI >> drivers / apps cannot rewrite it using the UEFI variable service). >> Then, >> >> - if the lock is enforced in SMM, then the variable will be locked >> from the OS as well, not just from 3rd party UEFI apps, so no PPI >> operations can ever be queued, >> >> - if the lock is "simulated" in ACPI or in non-SMM firmare code (= in >> the "runtime DXE driver" layer), then the lock can be circumvented >> by both 3rd party UEFI apps and the OS. > > > Regarding security of PPI pending operations, the spec clearly says > "The location for tracking the pending PPI > operation, including the tracking of necessary PLATFORM RESET > operations, does not need to be a secure or trusted location." (9.9 > p.32) Indeed, this is what the spec writes. In edk2, I found one variable that seems related, it's called "PhysicalPresenceFlags", in the 0F6499B1-E9AD-493D-B9C2-2F90815C6CBC variable namespace: [SecurityPkg/Include/Guid/PhysicalPresenceData.h] > // > // This variable is used to save TPM Management Flags and corresponding operations. > // It should be protected from malicious software (e.g. Set it as read-only variable). > // > #define PHYSICAL_PRESENCE_FLAGS_VARIABLE L"PhysicalPresenceFlags" > typedef struct { > UINT8 PPFlags; > } EFI_PHYSICAL_PRESENCE_FLAGS; In "SecurityPkg/Library/DxeTcgPhysicalPresenceLib/DxeTcgPhysicalPresenceLib.c", the TcgPhysicalPresenceLibProcessRequest() function is introduced like this: > /** > Check and execute the pending TPM request and Lock TPM. > > The TPM request may come from OS or BIOS. This API will display request information and wait > for user confirmation if TPM request exists. The TPM request will be sent to TPM device after > the TPM request is confirmed, and one or more reset may be required to make TPM request to > take effect. At last, it will lock TPM to prevent TPM state change by malware. > > This API should be invoked after console in and console out are all ready as they are required > to display request information and get user input to confirm the request. This API should also > be invoked as early as possible as TPM is locked in this function. > > **/ Part of the function: > // > // This flags variable controls whether physical presence is required for TPM command. > // It should be protected from malicious software. We set it as read-only variable here. > // > Status = gBS->LocateProtocol (&gEdkiiVariableLockProtocolGuid, NULL, (VOID **)&VariableLockProtocol); > if (!EFI_ERROR (Status)) { > Status = VariableLockProtocol->RequestToLock ( > VariableLockProtocol, > PHYSICAL_PRESENCE_FLAGS_VARIABLE, > &gEfiPhysicalPresenceGuid > ); > if (EFI_ERROR (Status)) { > DEBUG ((EFI_D_ERROR, "[TPM] Error when lock variable %s, Status = %r\n", PHYSICAL_PRESENCE_FLAGS_VARIABLE, Status)); > ASSERT_EFI_ERROR (Status); > } > } When the SMM driver stack is used, the variable lock service is composed of two halves (as expected): - "MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c" composes a request buffer, with the SMM_VARIABLE_FUNCTION_LOCK_VARIABLE command, and raises an SMI, - "MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c" and "MdeModulePkg/Universal/Variable/RuntimeDxe/VarCheck.c" set the (internal) property VAR_CHECK_VARIABLE_PROPERTY_READ_ONLY on the variable, in SMM code. Thus the variable lock is enforced in SMM, and the OS cannot use the UEFI variable services to modify the variable. (It could be possible that the ACPI method enters SMM with different parameters, and then SMM code modifies the variable *without* going through the outer variable services.) I don't know. On 02/08/18 16:52, Marc-André Lureau wrote: > I assume this is because the user has to confirm the pending operation > in pre-os console, so if some attacker wanted to clear the TPM, the > user would have to confirm it (same for other operation of flags > manipulation). That may not be the best security design, but at least, > the user could be in control. > > How does the UEFI runtime variable services verify the authenticity of > the requests? Or does it only check a request validity? I didn't find any particular verification for this variable. Thanks Laszlo

1 0

Saving a few bytes across a reboot
by Stefan Berger 09 Feb '18

09 Feb '18

Kevin, is it possible to save a few bytes, a pointer, across a reboot? I have tried to do this by allocating a memory chunk in the fsegement and storing the pointer there surrounded by 2 'magic' 32 bit values. When trying to find the magic values on reboot early in handle_post() it doesn't seem to find them anymore. Is there another memory segment where SeaBIOS could store the few bytes and find them again? Regards, Stefan

6 27

Re: [SeaBIOS] Failure to detect high-capacity SD card
by Kevin O'Connor 09 Feb '18

09 Feb '18

On Tue, Feb 06, 2018 at 07:38:22PM -0500, Chris wrote: > Re: https://mail.coreboot.org/pipermail/seabios/2017-October/011862.html > > Did this ever get resolved? I didn't see a response to the final log. > I'm experiencing the same thing on the same platform (ASUS C302 CAVE). > > Card brand doesn't seem to matter. I've tried 32GB Samsung EVO cards, > various SanDisk cards from 32GB to 128GB. None show up as boot options > in SeaBIOS. If I use the exact same data/layout except on a smaller > card like 1GB of any brand then it works no problem. > > Same large cards boot fine off an external USB card reader. It appears > to be an issue with the integrated SD card reader on the C302. > > I'm using the same latest MrChromeBox build from May 2017. No - the issue was not resolved. We looked at it, but could not figure out what the SD card (and/or controller) did not like about the seabios initialization sequence. The sd card would stop responding and it wasn't clear what seabios was doing different from linux (which apparently works fine on the same hardware). As Paul mentions, if you'd like us to look at this further, please include the debug logs of a session. It's possible additional tests on new hardware will reveal the issue. -Kevin

2 1

[Question] Debug Seabios by GDB with Qemu
by Liu, Jing2 08 Feb '18

08 Feb '18

Hello, I am using Seabios for qemu startup, and interested in the debugging by GDB to see how the bios works. Currently, I do it as https://www.seabios.org/Debugging said but met some problems so that couldn't move on. :( Could someone give some pointers on what I missed or have to do to enable the gdb debugging? Note: Arch: x86_64 PC CONFIG_DEBUG_SERIAL is enabled. CONFIG_RELOCATE_INIT is disabled. 1. After Qemu starts, I run "gdb out/rom32seg.o" in another session, and do "target remote localhost:1234", it warns me that "Selected architecture i386 is not compatible with reported target architecture i386:x86_64". But I didn't find any 64bit rom. 2. I can't set any breakpoints (e.g. maininit), because "Function maininit not defined". So where does seabios put the symbol table? And how to break the seabios functions when qemu starts? Looking forward to your response! Thanks, Jing

2 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS