TEST: Booted ASUS KFSN4-DRE with iPXE ROMs built in to CBFS; with this option set the on-board network ROMs were ignored while the iPXE ROMs executed normally.
Signed-off-by: Timothy Pearson tpearson@raptorengineeringinc.com --- src/Kconfig | 11 +++++++++++ src/optionroms.c | 3 +++ 2 files changed, 14 insertions(+)
diff --git a/src/Kconfig b/src/Kconfig index 45ca59c..9cac231 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -355,6 +355,17 @@ menu "BIOS interfaces" default y help Support finding and running option roms during POST. + config CBFS_OPTIONROMS_ONLY + depends on OPTIONROMS && COREBOOT_FLASH + bool "Only execute option ROMs stored in CBFS" + default "n" + help + Only execute option ROMs that are stored in CBFS. + Do not scan PCI bus for option ROMs. This is useful + if one or more of your PCI devices crash/hang SeaBIOS + when executing their option ROMs, but you need to use + one or more option ROMs (such as SeaVGABIOS) that were + loaded into CBFS. config OPTIONROMS_DEPLOYED depends on OPTIONROMS && QEMU bool "Option roms are already at 0xc0000-0xf0000" diff --git a/src/optionroms.c b/src/optionroms.c index 93d9d2f..fbcb6ca 100644 --- a/src/optionroms.c +++ b/src/optionroms.c @@ -253,6 +253,9 @@ copy_rom(struct rom_header *rom) static struct rom_header * map_pcirom(struct pci_device *pci) { + if (CONFIG_CBFS_OPTIONROMS_ONLY) + return NULL; + u16 bdf = pci->bdf; dprintf(6, "Attempting to map option rom on dev %02x:%02x.%x\n" , pci_bdf_to_bus(bdf), pci_bdf_to_dev(bdf), pci_bdf_to_fn(bdf));
On Wed, Feb 11, 2015 at 05:32:03PM -0600, Timothy Pearson wrote:
TEST: Booted ASUS KFSN4-DRE with iPXE ROMs built in to CBFS; with this option set the on-board network ROMs were ignored while the iPXE ROMs executed normally.
Signed-off-by: Timothy Pearson tpearson@raptorengineeringinc.com
Hi Timothy,
Thanks for providing the patch and sorry for the delay in reviewing.
src/Kconfig | 11 +++++++++++ src/optionroms.c | 3 +++ 2 files changed, 14 insertions(+)
diff --git a/src/Kconfig b/src/Kconfig index 45ca59c..9cac231 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -355,6 +355,17 @@ menu "BIOS interfaces" default y help Support finding and running option roms during POST.
- config CBFS_OPTIONROMS_ONLY
depends on OPTIONROMS && COREBOOT_FLASHbool "Only execute option ROMs stored in CBFS"default "n"helpOnly execute option ROMs that are stored in CBFS.Do not scan PCI bus for option ROMs. This is usefulif one or more of your PCI devices crash/hang SeaBIOSwhen executing their option ROMs, but you need to useone or more option ROMs (such as SeaVGABIOS) that wereloaded into CBFS.
In general, I prefer for these types of options to be set at runtime (by making a new CBFS file such as "etc/run-option-roms" and using the romfile_loadint() mechanism) instead of at compile time.
That said, it should already possible to prevent a particular option rom from running by creating a dummy option rom for that device in CBFS. That is, it should be possible to create a dummy cbfs file "pci1234,5678.rom" to prevent the option rom on PCI device 1234:5678 from running. Not sure if this fixes the issue you were seeing, but if so maybe the best fix is to just update the documentation.
-Kevin
On 02/13/2015 02:05 PM, Kevin O'Connor wrote:
On Wed, Feb 11, 2015 at 05:32:03PM -0600, Timothy Pearson wrote:
TEST: Booted ASUS KFSN4-DRE with iPXE ROMs built in to CBFS; with this option set the on-board network ROMs were ignored while the iPXE ROMs executed normally.
Signed-off-by: Timothy Pearsontpearson@raptorengineeringinc.com
Hi Timothy,
Thanks for providing the patch and sorry for the delay in reviewing.
src/Kconfig | 11 +++++++++++ src/optionroms.c | 3 +++ 2 files changed, 14 insertions(+)
diff --git a/src/Kconfig b/src/Kconfig index 45ca59c..9cac231 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -355,6 +355,17 @@ menu "BIOS interfaces" default y help Support finding and running option roms during POST.
- config CBFS_OPTIONROMS_ONLY
depends on OPTIONROMS&& COREBOOT_FLASHbool "Only execute option ROMs stored in CBFS"default "n"helpOnly execute option ROMs that are stored in CBFS.Do not scan PCI bus for option ROMs. This is usefulif one or more of your PCI devices crash/hang SeaBIOSwhen executing their option ROMs, but you need to useone or more option ROMs (such as SeaVGABIOS) that wereloaded into CBFS.In general, I prefer for these types of options to be set at runtime (by making a new CBFS file such as "etc/run-option-roms" and using the romfile_loadint() mechanism) instead of at compile time.
That said, it should already possible to prevent a particular option rom from running by creating a dummy option rom for that device in CBFS. That is, it should be possible to create a dummy cbfs file "pci1234,5678.rom" to prevent the option rom on PCI device 1234:5678 from running. Not sure if this fixes the issue you were seeing, but if so maybe the best fix is to just update the documentation.
-Kevin
This patch in particular guarantees that no matter what devices are plugged in (e.g. long after the BIOS has been flashed) they will not have their option ROMs executed. Its primary use is for those who want a blob-free system, e.g. for high-security applications.
The second patch in this series also operates slightly different from the proposed device ID-based override in that it allows the blacklisting of entire buses and devices based on their physical location on the bus instead of the exact device installed. I could easily see a use for any of the three methods depending on the exact needs of the end user.
On Fri, Feb 13, 2015 at 02:09:05PM -0600, Timothy Pearson wrote:
On 02/13/2015 02:05 PM, Kevin O'Connor wrote:
In general, I prefer for these types of options to be set at runtime (by making a new CBFS file such as "etc/run-option-roms" and using the romfile_loadint() mechanism) instead of at compile time.
That said, it should already possible to prevent a particular option rom from running by creating a dummy option rom for that device in CBFS. That is, it should be possible to create a dummy cbfs file "pci1234,5678.rom" to prevent the option rom on PCI device 1234:5678 from running. Not sure if this fixes the issue you were seeing, but if so maybe the best fix is to just update the documentation.
This patch in particular guarantees that no matter what devices are plugged in (e.g. long after the BIOS has been flashed) they will not have their option ROMs executed. Its primary use is for those who want a blob-free system, e.g. for high-security applications.
That makes sense, but I think it needs to be a runtime setting. I'll see if I can put together a quick patch to better show what I mean.
The documentation for SeaBIOS CBFS files currently lives in the coreboot wiki. I'll also see if I can move that into the SeaBIOS docs/ directory so that future changes like this can update both docs and code at the same time.
In any case, SeaBIOS is in a feature freeze for the next few days as we prepare for the next release.
-Kevin
Kevin O'Connor wrote:
This patch in particular guarantees that no matter what devices are plugged in (e.g. long after the BIOS has been flashed) they will not have their option ROMs executed.
That makes sense, but I think it needs to be a runtime setting.
Timothy's original approach is appealing more and more to me. It's a good way to know that the system will stay as it was when flashed.
Runtime setting - the argument there would be that if someone can change the flash contents to create a new CBFS file they could also replace the SeaBIOS payload, right?
It is sortof true, but it *is* slightly easier to write data into erased flash than to erase existing and then write something new.
//Peter
On Sat, Feb 14, 2015 at 03:15:42AM +0100, Peter Stuge wrote:
Kevin O'Connor wrote:
This patch in particular guarantees that no matter what devices are plugged in (e.g. long after the BIOS has been flashed) they will not have their option ROMs executed.
That makes sense, but I think it needs to be a runtime setting.
Timothy's original approach is appealing more and more to me. It's a good way to know that the system will stay as it was when flashed.
Runtime setting - the argument there would be that if someone can change the flash contents to create a new CBFS file they could also replace the SeaBIOS payload, right?
Right - if one can modify the flash then one can modify seabios, and so there is no appreciable security if an attacker can modify the flash.
I'd like the default SeaBIOS build to be useful for a wide audience. I view the Kconfig settings as a means to make smaller builds (for those with a small flash size) and as a means to select options that can't be auto-detected or configured at runtime. Using run-time options reduces the overall compile and test coverage (as more people are running the same binary).
-Kevin
On Fri, Feb 13, 2015 at 04:35:08PM -0500, Kevin O'Connor wrote:
On Fri, Feb 13, 2015 at 02:09:05PM -0600, Timothy Pearson wrote:
This patch in particular guarantees that no matter what devices are plugged in (e.g. long after the BIOS has been flashed) they will not have their option ROMs executed. Its primary use is for those who want a blob-free system, e.g. for high-security applications.
That makes sense, but I think it needs to be a runtime setting. I'll see if I can put together a quick patch to better show what I mean.
Below is an example of what I was suggesting (untested). The patch below uses the file "/etc/pci-optionroms" - 0 means don't run any option roms, 1 means run only the option rom for the primary vga device, 2 means run option roms for only non-vga devices, and 3 means run all option roms (the default).
-Kevin
diff --git a/src/optionroms.c b/src/optionroms.c index 93d9d2f..ed05870 100644 --- a/src/optionroms.c +++ b/src/optionroms.c @@ -20,6 +20,8 @@ #include "string.h" // memset #include "util.h" // get_pnp_offset
+static int EnforceChecksum, S3ResumeVga, RunPCIroms; +
/**************************************************************** * Helper functions @@ -60,8 +62,6 @@ call_bcv(u16 seg, u16 ip) __callrom(MAKE_FLATPTR(seg, 0), ip, 0); }
-static int EnforceChecksum; - // Verify that an option rom looks valid static int is_valid_rom(struct rom_header *rom) @@ -329,7 +329,7 @@ init_pcirom(struct pci_device *pci, int isvga, u64 *sources) , pci_bdf_to_bus(bdf), pci_bdf_to_dev(bdf), pci_bdf_to_fn(bdf) , pci->vendor, pci->device); struct rom_header *rom = lookup_hardcode(pci); - if (! rom) + if (!rom && RunPCIroms & (isvga ? 1 : 2)) rom = map_pcirom(pci); if (! rom) // No ROM present. @@ -416,7 +416,6 @@ optionrom_setup(void) * VGA init ****************************************************************/
-static int S3ResumeVga; int ScreenAndDebug; struct rom_header *VgaROM;
@@ -432,6 +431,7 @@ vgarom_setup(void) // Load some config settings that impact VGA. EnforceChecksum = romfile_loadint("etc/optionroms-checksum", 1); S3ResumeVga = romfile_loadint("etc/s3-resume-vga-init", CONFIG_QEMU); + RunPCIroms = romfile_loadint("etc/pci-optionroms", 3); ScreenAndDebug = romfile_loadint("etc/screen-and-debug", 1);
if (CONFIG_OPTIONROMS_DEPLOYED) {
On 02/14/2015 11:02 AM, Kevin O'Connor wrote:
On Fri, Feb 13, 2015 at 04:35:08PM -0500, Kevin O'Connor wrote:
On Fri, Feb 13, 2015 at 02:09:05PM -0600, Timothy Pearson wrote:
This patch in particular guarantees that no matter what devices are plugged in (e.g. long after the BIOS has been flashed) they will not have their option ROMs executed. Its primary use is for those who want a blob-free system, e.g. for high-security applications.
That makes sense, but I think it needs to be a runtime setting. I'll see if I can put together a quick patch to better show what I mean.
Below is an example of what I was suggesting (untested). The patch below uses the file "/etc/pci-optionroms" - 0 means don't run any option roms, 1 means run only the option rom for the primary vga device, 2 means run option roms for only non-vga devices, and 3 means run all option roms (the default).
-Kevin
<patch snipped>
That's fine with me; it retains the same basic functionality but allows slightly more control.
Before I test and put together a formal patch submission are there any objections from anyone else?
Am Samstag, den 14.02.2015, 18:33 -0600 schrieb Timothy Pearson:
On 02/14/2015 11:02 AM, Kevin O'Connor wrote:
On Fri, Feb 13, 2015 at 04:35:08PM -0500, Kevin O'Connor wrote:
On Fri, Feb 13, 2015 at 02:09:05PM -0600, Timothy Pearson wrote:
This patch in particular guarantees that no matter what devices are plugged in (e.g. long after the BIOS has been flashed) they will not have their option ROMs executed. Its primary use is for those who want a blob-free system, e.g. for high-security applications.
That makes sense, but I think it needs to be a runtime setting. I'll see if I can put together a quick patch to better show what I mean.
Below is an example of what I was suggesting (untested). The patch below uses the file "/etc/pci-optionroms" - 0 means don't run any option roms, 1 means run only the option rom for the primary vga device, 2 means run option roms for only non-vga devices, and 3 means run all option roms (the default).
-Kevin
<patch snipped>
That's fine with me; it retains the same basic functionality but allows slightly more control.
Before I test and put together a formal patch submission are there any objections from anyone else?
Besides the file name, I do not have any objections.
Maybe use `/etc/pci-optionrom-exec` and use 0 for running no Option ROMs, 1 for running all Option ROMs, 2 for running Option ROM of primary VGA device and 3 for Option ROMs of non-VGA devices.
Thanks,
Paul
-
Kevin O'Connor -
Paul Menzel -
Peter Stuge -
Timothy Pearson