[SeaBIOS] [PATCH] optionrom: disallow int19 redirect for pnp roms.

Laszlo Ersek lersek at redhat.com
Wed Nov 28 18:50:50 CET 2018


On 11/28/18 16:51, Kevin O'Connor wrote:
> On Wed, Nov 28, 2018 at 12:14:07PM +0100, Laszlo Ersek wrote:
>> Right. Before I raised my short question about *not* short-circuiting
>> get_pnp_rom() with "isvga" set, I had read through the BZ, and I was
>> *very* tempted to say "this is what's wrong with our industry". :) The
>> oprom in question is mind-bogglingly broken, from the discussion /
>> analysis in the BZ.
>>
>> (I'm sure somewhere deep in an internal bug tracking system at the card
>> vendor there is a ticket about some broken platform BIOS where the BEV
>> wouldn't work, and they had to hook Int19h.)
> 
> Right - fundamental to X86 booting is the idea that firmware
> developers write code, PC manufacturers write code, peripheral
> manufacturers write code, and only users test all the code together.
> It's a broken workflow.  It's been nearly 40 years and X86 is still
> stuck in this broken workflow.
> 
>>>> I'm leery of making a change like this, because there's a good chance
>>>> it will break something in some other obscure software.
>>>
>>> I've added a rather verbose message printing some information about the
>>> rom because of that.
>>>
>>>> I think fixing this in iPXE would be preferable if possible.
>>>
>>> See above. ipxe doesn't need fixing.
>>
>> I support the addition of this "safety code", and I tend to agree (with
>> the BZ discussion) that making it *dynamically* configurable could be
>> difficult and/or overkill.
>>
>> Kevin, would you feel easier about the Int19h vector restoration if it
>> were controlled by a new, static, config knob?
> 
> If we could do it safely that would be fine.  My fear is that it
> introduces a regression.  A new config option would be okay, but it
> doesn't sound like that will help, as it seems that once one narrows
> down the problem to a bad behaving optionrom, one could just as easily
> block that optionrom instead..

Do you mean that a "blacklist" should be added (a static array of
checksums, of known-bad ROM images)?

Thanks,
Laszlo

> I'm not sure what the best choice is.
> 
> -Kevin
> 




More information about the SeaBIOS mailing list