File: pci_optrom_blacklist.txt
Syntax: <bus>,<device>,<function> Numbers or a single wildcard ('*') are allowed Each blacklisted device is placed on separate line
Examples: Blacklist device 01:04.0: 1,4,0 Blacklist all devices on bus 5: 5,*,*
TEST: Booted ASUS KFSN4-DRE with iPXE ROMs built in to CBFS; with the two add-on network devices blacklisted the add-on network ROMs were ignored while the on-board iPXE ROMs executed normally.
Signed-off-by: Timothy Pearson tpearson@raptorengineeringinc.com --- src/optionroms.c | 112 +++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 111 insertions(+), 1 deletion(-)
diff --git a/src/optionroms.c b/src/optionroms.c index fbcb6ca..44967e7 100644 --- a/src/optionroms.c +++ b/src/optionroms.c @@ -1,5 +1,6 @@ // Option rom scanning code. // +// Copyright (C) 2015 Timothy Pearson tpearson@raptorengineeringinc.com // Copyright (C) 2008 Kevin O'Connor kevin@koconnor.net // Copyright (C) 2002 MandrakeSoft S.A. // @@ -346,12 +347,119 @@ init_pcirom(struct pci_device *pci, int isvga, u64 *sources) * Non-VGA option rom init ****************************************************************/
+u8 char_is_digit(const char c) { + if ((c >= '0') && (c <= '9')) + return 1; + else + return 0; +} + +int atoi(const char* c) +{ + int value = 0; + + while (char_is_digit(*c)) { + value *= 10; + value += (int) (*c - '0'); + c++; + } + + return value; +} + +/* 256: Match none + * 257: Match any + */ +struct pci_optrom_blacklist_entry { + u16 bus; + u16 device; + u16 function; +}; + +u8 pci_device_option_rom_is_blacklisted(struct pci_device *pci, struct pci_optrom_blacklist_entry *pci_optrom_blacklist, int pci_optrom_blacklist_count) +{ + if (!pci) + return 0; + + int i; + for (i=0; i<pci_optrom_blacklist_count; i++) { + if ((pci_optrom_blacklist[i].bus == pci_bdf_to_bus(pci->bdf)) || (pci_optrom_blacklist[i].bus == 257)) { + if ((pci_optrom_blacklist[i].device == pci_bdf_to_dev(pci->bdf)) || (pci_optrom_blacklist[i].device == 257)) { + if ((pci_optrom_blacklist[i].function == pci_bdf_to_fn(pci->bdf)) || (pci_optrom_blacklist[i].function == 257)) { + return 1; + } + } + } + } + + return 0; +} + void optionrom_setup(void) { if (! CONFIG_OPTIONROMS) return;
+ struct pci_optrom_blacklist_entry *pci_optrom_blacklist = NULL; + int pci_optrom_blacklist_count = 0; + + dprintf(3, "Checking for PCI option ROM blacklist\n"); + int filesize; + u8 *filedata = romfile_loadfile("pci_optrom_blacklist.txt", &filesize); + if (filedata) { + int i = 0; + while (filedata[i]) { + if (filedata[i] == '\n') + pci_optrom_blacklist_count++; + i++; + } + pci_optrom_blacklist = malloc_tmphigh(sizeof(struct pci_optrom_blacklist_entry) + * pci_optrom_blacklist_count); + int bdf_parse = 0; + int j = 0; + i=0; + u16 value = 0; + pci_optrom_blacklist_count = 0; + char bdf_tmp[4]; + while (filedata[i]) { + if ((j > 3) || (bdf_parse > 2)) { + dprintf(1, "WARNING: Incorrect value in PCI option ROM blacklist\n"); + pci_optrom_blacklist[pci_optrom_blacklist_count].bus = 256; + pci_optrom_blacklist[pci_optrom_blacklist_count].device = 256; + pci_optrom_blacklist[pci_optrom_blacklist_count].function = 256; + } else { + bdf_tmp[j] = filedata[i]; + j++; + if ((filedata[i] == ',') || (filedata[i] == '\n')) { + bdf_tmp[j] = 0; + if (bdf_tmp[0] == '*') + value = 257; + else + value = atoi(bdf_tmp); + if (bdf_parse == 0) + pci_optrom_blacklist[pci_optrom_blacklist_count].bus = value; + if (bdf_parse == 1) + pci_optrom_blacklist[pci_optrom_blacklist_count].device = value; + if (bdf_parse == 2) + pci_optrom_blacklist[pci_optrom_blacklist_count].function = value; + bdf_parse++; + j=0; + } + } + if (filedata[i] == '\n') { + dprintf(3, "PCI device %02x:%02x.%x added to PCI option ROM blacklist\n", + pci_optrom_blacklist[pci_optrom_blacklist_count].bus, + pci_optrom_blacklist[pci_optrom_blacklist_count].device, + pci_optrom_blacklist[pci_optrom_blacklist_count].function); + pci_optrom_blacklist_count++; + bdf_parse=0; + } + i++; + } + free(filedata); + } + dprintf(1, "Scan for option roms\n"); u64 sources[(BUILD_BIOS_ADDR - BUILD_ROM_START) / OPTION_ROM_ALIGN]; memset(sources, 0, sizeof(sources)); @@ -373,13 +481,15 @@ optionrom_setup(void) foreachpci(pci) { if (pci->class == PCI_CLASS_DISPLAY_VGA || pci->have_driver) continue; - init_pcirom(pci, 0, sources); + if (!pci_device_option_rom_is_blacklisted(pci, pci_optrom_blacklist, pci_optrom_blacklist_count)) + init_pcirom(pci, 0, sources); }
// Find and deploy CBFS roms not associated with a device. run_file_roms("genroms/", 0, sources); } rom_reserve(0); + free(pci_optrom_blacklist);
// All option roms found and deployed - now build BEV/BCV vectors.
Am Mittwoch, den 11.02.2015, 17:32 -0600 schrieb Timothy Pearson:
File: pci_optrom_blacklist.txt
Syntax: <bus>,<device>,<function> Numbers or a single wildcard ('*') are allowed Each blacklisted device is placed on separate line
. at end of sentences. ;-)
Examples: Blacklist device 01:04.0: 1,4,0 Blacklist all devices on bus 5: 5,*,*
TEST: Booted ASUS KFSN4-DRE with iPXE ROMs built in to CBFS; with the two add-on network devices blacklisted the add-on network ROMs were ignored while the on-board iPXE ROMs executed normally.
Signed-off-by: Timothy Pearson tpearson@raptorengineeringinc.com
src/optionroms.c | 112 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
Your MUA Thunderbird wrapped the lines. Please use the preformat(?) option for patches. I think that was the last formal problem you could hit with contributing patches to a mailing list. And congratulations, you had to deal with all the problems, there are, and solved them. ;-)
1 file changed, 111 insertions(+), 1 deletion(-)
diff --git a/src/optionroms.c b/src/optionroms.c index fbcb6ca..44967e7 100644
[…]
Besides that, the patch looks good to me.
Thanks,
Paul
On Wed, Feb 11, 2015 at 05:32:36PM -0600, Timothy Pearson wrote:
File: pci_optrom_blacklist.txt
Syntax: <bus>,<device>,<function> Numbers or a single wildcard ('*') are allowed Each blacklisted device is placed on separate line
Examples: Blacklist device 01:04.0: 1,4,0 Blacklist all devices on bus 5: 5,*,*
TEST: Booted ASUS KFSN4-DRE with iPXE ROMs built in to CBFS; with the two add-on network devices blacklisted the add-on network ROMs were ignored while the on-board iPXE ROMs executed normally.
Thanks for submitting.
It's possible to blacklist the execution of an option rom on a particular device today by creating a dummy option rom for that device in CBFS. Given this, is this patch still needed?
Putting PCI bus/dev/fn ids in CBFS isn't a great solution because (I'm told) some boards can change BDFs from one boot to another. (In general, BDFs are not stable.) That's why the existing option rom mechanism uses vendor/device ids.
BTW, the white space in your patch got corrupted during delivery.
-Kevin
On 02/13/2015 02:10 PM, Kevin O'Connor wrote:
On Wed, Feb 11, 2015 at 05:32:36PM -0600, Timothy Pearson wrote:
File: pci_optrom_blacklist.txt
Syntax: <bus>,<device>,<function> Numbers or a single wildcard ('*') are allowed Each blacklisted device is placed on separate line
Examples: Blacklist device 01:04.0: 1,4,0 Blacklist all devices on bus 5: 5,*,*
TEST: Booted ASUS KFSN4-DRE with iPXE ROMs built in to CBFS; with the two add-on network devices blacklisted the add-on network ROMs were ignored while the on-board iPXE ROMs executed normally.
Thanks for submitting.
It's possible to blacklist the execution of an option rom on a particular device today by creating a dummy option rom for that device in CBFS. Given this, is this patch still needed?
As mentioned in my previous message yes, I believe the additional functionality offered by this patch is needed. At least on my coreboot-based board here the BDFs are stable and it is useful to, for example, blacklist the option ROMs on the add-on slots to avoid a potential failure to boot when the hardware is inevitably reconfigured in the future.
Putting PCI bus/dev/fn ids in CBFS isn't a great solution because (I'm told) some boards can change BDFs from one boot to another. (In general, BDFs are not stable.) That's why the existing option rom mechanism uses vendor/device ids.
BTW, the white space in your patch got corrupted during delivery.
If you are considering using the patch I will re-send.
Thanks!
On Fri, Feb 13, 2015 at 02:16:13PM -0600, Timothy Pearson wrote:
On 02/13/2015 02:10 PM, Kevin O'Connor wrote:
On Wed, Feb 11, 2015 at 05:32:36PM -0600, Timothy Pearson wrote:
File: pci_optrom_blacklist.txt
Syntax: <bus>,<device>,<function> Numbers or a single wildcard ('*') are allowed Each blacklisted device is placed on separate line
Examples: Blacklist device 01:04.0: 1,4,0 Blacklist all devices on bus 5: 5,*,*
TEST: Booted ASUS KFSN4-DRE with iPXE ROMs built in to CBFS; with the two add-on network devices blacklisted the add-on network ROMs were ignored while the on-board iPXE ROMs executed normally.
Thanks for submitting.
It's possible to blacklist the execution of an option rom on a particular device today by creating a dummy option rom for that device in CBFS. Given this, is this patch still needed?
As mentioned in my previous message yes, I believe the additional functionality offered by this patch is needed. At least on my coreboot-based board here the BDFs are stable and it is useful to, for example, blacklist the option ROMs on the add-on slots to avoid a potential failure to boot when the hardware is inevitably reconfigured in the future.
I think I need to better understand your use-case. Can you further describe the problem you are seeing. Is there some option rom that works on a proprietary BIOS, but fails to work on SeaBIOS? I'm particularly interested in the situation you face as opposed to features a possible future user may desire.
Thanks, -Kevin
On 02/13/2015 03:40 PM, Kevin O'Connor wrote:
On Fri, Feb 13, 2015 at 02:16:13PM -0600, Timothy Pearson wrote:
On 02/13/2015 02:10 PM, Kevin O'Connor wrote:
On Wed, Feb 11, 2015 at 05:32:36PM -0600, Timothy Pearson wrote:
File: pci_optrom_blacklist.txt
Syntax: <bus>,<device>,<function> Numbers or a single wildcard ('*') are allowed Each blacklisted device is placed on separate line
Examples: Blacklist device 01:04.0: 1,4,0 Blacklist all devices on bus 5: 5,*,*
TEST: Booted ASUS KFSN4-DRE with iPXE ROMs built in to CBFS; with the two add-on network devices blacklisted the add-on network ROMs were ignored while the on-board iPXE ROMs executed normally.
Thanks for submitting.
It's possible to blacklist the execution of an option rom on a particular device today by creating a dummy option rom for that device in CBFS. Given this, is this patch still needed?
As mentioned in my previous message yes, I believe the additional functionality offered by this patch is needed. At least on my coreboot-based board here the BDFs are stable and it is useful to, for example, blacklist the option ROMs on the add-on slots to avoid a potential failure to boot when the hardware is inevitably reconfigured in the future.
I think I need to better understand your use-case. Can you further describe the problem you are seeing. Is there some option rom that works on a proprietary BIOS, but fails to work on SeaBIOS? I'm particularly interested in the situation you face as opposed to features a possible future user may desire.
Thanks, -Kevin
This particular patch was a favor to Peter Stuge; as such I don't have a use case myself for it. However the initial patch to disable all option ROMs was for a system on which I did not want any unknown binary code to ever execute. This has multiple applications ranging from useful (high-security systems) to informational (proving that yes, you can have a fully functional system utilizing only open source software).
On 02/13/2015 04:42 PM, Timothy Pearson wrote:
On 02/13/2015 03:40 PM, Kevin O'Connor wrote:
On Fri, Feb 13, 2015 at 02:16:13PM -0600, Timothy Pearson wrote:
This particular patch was a favor to Peter Stuge; as such I don't have a use case myself for it. However the initial patch to disable all option ROMs was for a system on which I did not want any unknown binary code to ever execute. This has multiple applications ranging from useful (high-security systems) to informational (proving that yes, you can have a fully functional system utilizing only open source software).
Out of curiosity is this patch just going to be abandoned then? It took some time to put together.
Thanks!
On Tue, Feb 17, 2015 at 04:28:42PM -0600, Timothy Pearson wrote:
On 02/13/2015 04:42 PM, Timothy Pearson wrote:
On 02/13/2015 03:40 PM, Kevin O'Connor wrote:
On Fri, Feb 13, 2015 at 02:16:13PM -0600, Timothy Pearson wrote:
This particular patch was a favor to Peter Stuge; as such I don't have a use case myself for it. However the initial patch to disable all option ROMs was for a system on which I did not want any unknown binary code to ever execute. This has multiple applications ranging from useful (high-security systems) to informational (proving that yes, you can have a fully functional system utilizing only open source software).
Out of curiosity is this patch just going to be abandoned then? It took some time to put together.
Hi Timothy,
Thanks for submitting the patch. However, with BDFs not being stable on some boards and with an existing mechanism available to blacklist option roms by vendor/device id, I don't think it makes sense to add that patch to the master seabios repo. Your other patch to disable PCI option roms looks fine to me.
-Kevin
On 02/18/2015 02:09 PM, Kevin O'Connor wrote:
On Tue, Feb 17, 2015 at 04:28:42PM -0600, Timothy Pearson wrote:
On 02/13/2015 04:42 PM, Timothy Pearson wrote:
On 02/13/2015 03:40 PM, Kevin O'Connor wrote:
On Fri, Feb 13, 2015 at 02:16:13PM -0600, Timothy Pearson wrote:
This particular patch was a favor to Peter Stuge; as such I don't have a use case myself for it. However the initial patch to disable all option ROMs was for a system on which I did not want any unknown binary code to ever execute. This has multiple applications ranging from useful (high-security systems) to informational (proving that yes, you can have a fully functional system utilizing only open source software).
Out of curiosity is this patch just going to be abandoned then? It took some time to put together.
Hi Timothy,
Thanks for submitting the patch. However, with BDFs not being stable on some boards and with an existing mechanism available to blacklist option roms by vendor/device id, I don't think it makes sense to add that patch to the master seabios repo. Your other patch to disable PCI option roms looks fine to me.
-Kevin
OK, thank you for the clarification. The other patch is all I needed anyway so I look forward to seeing it in the SeaBIOS tree.
Thanks!
-
Kevin O'Connor -
Paul Menzel -
Timothy Pearson