[SeaBIOS] [PATCH] optionrom: disallow int19 redirect for pnp roms.
lersek at redhat.com
Wed Nov 28 12:14:07 CET 2018
On 11/28/18 07:24, Gerd Hoffmann wrote:
> On Tue, Nov 27, 2018 at 09:19:09PM -0500, Kevin O'Connor wrote:
>> On Tue, Nov 27, 2018 at 01:10:38PM +0100, Gerd Hoffmann wrote:
>>> Check whenever pnp roms attempt to redirect int19, and in case it does
>>> log a message and undo the redirect.
>>> A pnp rom should not need this, we have BEVs and BCVs for that.
>>> Nevertheless there are roms in the wild which are redirecting int19.
>>> At least some BIOS implementations for physical hardware have a config
>>> option in the setup to allow/disallow int19 redirections, so just not
>>> allowing this seems to be the way to deal with this situation.
>>> Buglink: https://bugzilla.redhat.com//show_bug.cgi?id=1642135
>> That is very odd. I'm pretty sure iPXE normally does register itself
>> as a BEV - any idea why it's now hooking int19?
> It's not ipxe.
> It is the rom of a intel nic, attached to a guest via pci passthrough.
> It does both, register bev and hook int19. No clue why. The only
> reason I can think of is backward compatibility to firmware so old that
> it doesn't know pnp roms. Which is a silly thing in pci express
> hardware. Maybe they carry forward that code since decades ...
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.)
>> 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?
More information about the SeaBIOS