[SeaBIOS] [PATCH] optionrom: disallow int19 redirect for pnp roms.
Kevin O'Connor
kevin at koconnor.net
Wed Nov 28 16:51:10 CET 2018
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..
I'm not sure what the best choice is.
-Kevin
More information about the SeaBIOS
mailing list