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).