SeaBIOS

seabios@seabios.org

3783 discussions

Re: [SeaBIOS] [PATCH 00/10] Some TPM simplifications
by Kevin O'Connor 07 Jan '16

07 Jan '16

On Tue, Jan 05, 2016 at 10:07:54PM -0500, Stefan Berger wrote: > "Kevin O'Connor" <kevin(a)koconnor.net> wrote on 01/05/2016 08:55:51 PM: > > Then it sounds like the only time we need to call tpm_set_failure is > > on a failure of a TPM_ORD_Extend command. It might also make sense to > > deactivate the TPM if we detect the hardware but don't have the acpi > > tables present. > > I would also deactivate it if it returned an error to > TPM_ORD_Startup, TPM_ORD_SelfTestFull. Since the menu is written in > such a way that the user only has the choices that are valid for the > current state, also those commands have to work, unless the TPM is > defective. Or is that too strict? Attempting to deactivate if TPM_ORD_Startup or TPM_ORD_SelfTestFull fail makes sense. I wonder if the code could attempt to assert physical presence in tpm_startup() and only enable the tpm menu if that succeeds. BTW, if I'm reading the specs correctly, CMD_ENABLE is likely to fail on real hardware as manufacturers are supposed to set LifetimeLock at the factory. It also appears that CMD_ENABLE alters non volatile memory, so writing it on every boot may cause wear on the device? -Kevin

2 1

Re: [SeaBIOS] [PATCH 00/10] Some TPM simplifications
by Kevin O'Connor 06 Jan '16

06 Jan '16

On Tue, Jan 05, 2016 at 05:05:20PM -0500, Stefan Berger wrote: > "Kevin O'Connor" <kevin(a)koconnor.net> wrote on 01/05/2016 03:35:35 PM: [...] > > - Take "measurements" during the boot process so that later on users > > can verify if some low-level code has changed (and thus attempt to > > identify if malicious code may have been inserted into the > > firmware). > > > > - The major requirement here seems to be that if we can't take a > > measurement that we either "cap" measurements or shutdown the TPM. > > If we don't do this, it opens the possibility of a malicious > > program forging measurements. > > That's correct. We don't cap the measurements but try to temporarily > deactivate the TPM until the next reboot. > > > > > - It's also useful to skip taking measurements if the TPM device is > > not present so that we don't waste CPU time taking measurements > > that will never be used. > > Correct. Then it sounds like the only time we need to call tpm_set_failure is on a failure of a TPM_ORD_Extend command. It might also make sense to deactivate the TPM if we detect the hardware but don't have the acpi tables present. > > - Implement physical presence capability so that critical settings in > > the TPM can only be changed by someone that can prove they are > > physically present at the hardware (and thus attempt to prevent > > malicious code that temporarily obtains escalated privileges from > > altering these important settings). > > > > - The major requirement here seems to be that the "physical > > presence" lock always be set prior to starting the boot loader. > > Yes, we have to give up physical presence and lock that. Does deactivating also lock the physical presence? The tpm_prepboot() code may not run if the tpm is in a "not working" state. -Kevin

2 1

Re: [SeaBIOS] [PATCH 00/10] Some TPM simplifications
by Kevin O'Connor 06 Jan '16

06 Jan '16

On Tue, Jan 05, 2016 at 02:05:55PM -0500, Stefan Berger wrote: > "Kevin O'Connor" <kevin(a)koconnor.net> wrote on 01/05/2016 12:16:18 PM: > > On Tue, Dec 29, 2015 at 07:17:40PM -0500, Kevin O'Connor wrote: > > > The following series involves some code reorganization in the TPM code > > > that I found useful in understanding the code. > > > > FYI, I committed patches 1-9 (after some bug fixes). > > The result of the 2nd patch set also looks good. Thanks - I pushed most of that series as well. I've been looking further at error recovery in the TPM code. I'm not sure I fully understand what needs to be done on an error. If I understand it correctly, the SeaBIOS TPM code has three major requirements: - Pass through commands from the 16bit bios interface to the TPM. This is useful for bootloaders/oproms that don't have a TPM driver. - I think the only requirement for error recovery here is that we return an appropriate error code to the caller of the 16bit BIOS interface. - Take "measurements" during the boot process so that later on users can verify if some low-level code has changed (and thus attempt to identify if malicious code may have been inserted into the firmware). - The major requirement here seems to be that if we can't take a measurement that we either "cap" measurements or shutdown the TPM. If we don't do this, it opens the possibility of a malicious program forging measurements. - It's also useful to skip taking measurements if the TPM device is not present so that we don't waste CPU time taking measurements that will never be used. - Implement physical presence capability so that critical settings in the TPM can only be changed by someone that can prove they are physically present at the hardware (and thus attempt to prevent malicious code that temporarily obtains escalated privileges from altering these important settings). - The major requirement here seems to be that the "physical presence" lock always be set prior to starting the boot loader. And, of course, we need to implement the ability to change the critical settings (via the tpm menu). Does the above seem correct? -Kevin

2 1

Re: [SeaBIOS] eDP Init Failure on Broadwell
by Kevin O'Connor 06 Jan '16

06 Jan '16

On Sun, Jan 03, 2016 at 07:33:14PM +0000, CoolStar Organization wrote: > Here's the cbmem with the updated patch. Thanks. To summarize our conversation on IRC, it looks like some hardware flags for this board are changed in coreboot that impact the option rom. The flags are set after coreboot attempts to run the option rom and before seabios starts executing, which is why different behavior is seen when coreboot runs the option rom vs seabios running it. -Kevin

1 0

[PATCH 0/8] TPM return code simplifications
by Kevin O'Connor 06 Jan '16

06 Jan '16

Hi Stefan, I cleaned up the additional patches I mentioned yesterday. Some time back, you posted a series of patches that removed the use of TCG 16bit BIOS structs from internal functions. Many of those functions were still using return codes from the spec though. I found using these return codes in internal functions to be annoying because they conflict with the TIS return codes. This series mostly just separates out the return codes so that only the TCG 16bit BIOS functions deal with the TCG 16bit BIOS return codes. This series is on top of patches 1-9 of the previous series (it replaces patch 10 of the previous series). Both series are also available at: https://github.com/KevinOConnor/seabios/tree/testing I'm not currently planning any other TPM changes after these. -Kevin Kevin O'Connor (8): tpm: Don't return a status from external bios measurement functions tpm: No need to check the return status of measurements tpm: Don't call tpm_set_failure() from tpm_log_extend_event() tpm: Don't use 16bit BIOS return codes in build_and_send_cmd() tpm: Don't use 16bit BIOS return codes in tpm_log_event() tpm: Don't use 16bit BIOS return codes in tpmhw_* functions tpm: Don't use 16bit BIOS return codes in TPM menu functions tpm: Replace build_and_send_cmd with tpm_send_cmd and tpm_send_check_cmd src/hw/tpm_drivers.c | 20 +- src/hw/tpm_drivers.h | 2 +- src/tcgbios.c | 718 +++++++++++++++++++-------------------------------- src/tcgbios.h | 8 +- 4 files changed, 287 insertions(+), 461 deletions(-) -- 2.5.0

3 12

[PATCH 00/10] Some TPM simplifications
by Kevin O'Connor 06 Jan '16

06 Jan '16

The following series involves some code reorganization in the TPM code that I found useful in understanding the code. Patches 3-5 simplify the hardware interface by only exporting three commands to the underlying TIS hardware (tpmhw_probe, tpmhw_transmit, tpmhw_set_timeouts). Patches 8-10 simplify the parameters to the build_and_send_cmd() function. The remaining patches are mostly just code reorg. I have only compile tested these changes. -Kevin Kevin O'Connor (10): tpm: Add banner separating the TCG bios interface code from TCG menu code tpm: Avoid macro expansion of tpm request / response structs tpm: Simplify hardware probe and detection checks tpm: Add wrapper function tpm_set_timeouts() tpm: Move TPM hardware functions from tcgbios.c to hw/tpm_drivers.c tpm: Rework TPM interface shutdown support tpm: Simplify tcpa probe tpm: Introduce tpm_get_capability() helper function tpm: Eliminate response buffer parameter from build_and_send_cmd() tpm: Return returnCode from build_and_send_cmd() instead of via pointer param src/hw/tpm_drivers.c | 84 ++++++ src/hw/tpm_drivers.h | 28 +- src/std/tcg.h | 55 ++-- src/tcgbios.c | 704 +++++++++++++++------------------------------------ 4 files changed, 317 insertions(+), 554 deletions(-) -- 2.5.0

3 19

[PATCH] pci: panic when out of bus numbers
by Marcel Apfelbaum 05 Jan '16

05 Jan '16

Currently the bios goes into an endless loop if more than 255 PCI buses are requested. Change that to panic which is preferred in this case. Signed-off-by: Marcel Apfelbaum <marcel(a)redhat.com> --- Hi, I am well aware that this is not a common scenario, but the bug was found and maybe it deserves a little attention. I opted for using panic because I saw it used for other scenarios where the bios is out of resources. Another way to look at this would be to *stop* registering buses over 255 and loose some of the devices, but bring the system up. Thanks, Marcel src/fw/pciinit.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index c31c2fa..5da6cf6 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -469,6 +469,9 @@ pci_bios_init_bus_rec(int bus, u8 *pci_bus) u8 secbus = pci_config_readb(bdf, PCI_SECONDARY_BUS); (*pci_bus)++; + if (!(*pci_bus)) { + panic("PCI: out of bus numbers!\n"); + } if (*pci_bus != secbus) { dprintf(1, "PCI: secondary bus = 0x%x -> 0x%x\n", secbus, *pci_bus); -- 2.4.3

4 4

Re: [SeaBIOS] eDP Init Failure on Broadwell
by Kevin O'Connor 04 Jan '16

04 Jan '16

On Sun, Jan 03, 2016 at 07:13:03PM +0000, CoolStar Organization wrote: > Here is the cbmem with the debug patch. Can you try with this debug patch instead? -Kevin --- a/src/vgahooks.c +++ b/src/vgahooks.c @@ -299,10 +299,19 @@ winent_mb6047_setup(struct pci_device *pci) * Entry and setup ****************************************************************/ +#include "stacks.h" + +void VISIBLE32FLAT +dummy_debug(struct bregs *regs) +{ + debug_enter(regs, 1); +} + // Main 16bit entry point void handle_155f(struct bregs *regs) { + call32(dummy_debug, MAKE_FLATPTR(GET_SEG(SS), regs), 0); if (!CONFIG_VGAHOOKS) { handle_155fXX(regs); return; @@ -320,6 +329,7 @@ handle_155f(struct bregs *regs) void handle_157f(struct bregs *regs) { + call32(dummy_debug, MAKE_FLATPTR(GET_SEG(SS), regs), 0); if (!CONFIG_VGAHOOKS) { handle_157fXX(regs); return;

1 0

Re: [SeaBIOS] eDP Init Failure on Broadwell
by Kevin O'Connor 04 Jan '16

04 Jan '16

On Sun, Jan 03, 2016 at 06:48:34PM +0000, CoolStar Organization wrote: > I'm using SeaBIOS 1.9.0 stable. I'm building with make/gcc on Ubuntu 14.04 > LTS. Will try those patches in a few. Are you building from the git repo or from a tar file? Can you cut-and-paste the build output from "make clean ; make"? -Kevin

2 1

Re: [SeaBIOS] eDP Init Failure on Broadwell
by Kevin O'Connor 04 Jan '16

04 Jan '16

On Sun, Jan 03, 2016 at 06:29:16PM +0000, CoolStar Organization wrote: > I have attached 4 cbmem's. > > cbmem.txt is with coreboot running the ROM & seabios using SeaVGABIOS. eDP > Inits properly and all is fine. > > I thought textmode might be the issue so I added a bootsplash but still no > dice :/ > > cbmem-seasplash.txt is with seabios running the VGA Bios and no display. > cbmem-seasplashhdmi.txt is with seabios running the VGA BIOS and display on > an external HDMI display. > > cbmem-seasplashnotext.txt is same as cbmem-seasplash.txt except I commented > out code in enable_vga_console after the dprintf to see if disabling text > mode would do anything. Can you apply the seabios patch below and run again with eDP and seabios running the option rom? BTW, it looks like the build could not extract the seabios version. What seabios version are you using? Are you using an unusual build environment? -Kevin --- a/src/vgahooks.c +++ b/src/vgahooks.c @@ -303,6 +303,7 @@ winent_mb6047_setup(struct pci_device *pci) void handle_155f(struct bregs *regs) { + debug_enter(regs, 1); if (!CONFIG_VGAHOOKS) { handle_155fXX(regs); return; @@ -320,6 +321,7 @@ handle_155f(struct bregs *regs) void handle_157f(struct bregs *regs) { + debug_enter(regs, 1); if (!CONFIG_VGAHOOKS) { handle_157fXX(regs); return;

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS