linux-kernel - Re: [Intel-gfx] [PATCH] drm/intel: Only smash VGA SR01 register if intel is default VGA device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131217185742.GP22448@nuc-i3427.alporthouse.com>
Date:	Tue, 17 Dec 2013 18:57:42 +0000
From:	Chris Wilson <chris@...is-wilson.co.uk>
To:	Keith Packard <keithp@...thp.com>
Cc:	intel-gfx@...ts.freedesktop.org,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/intel: Only smash VGA SR01 register if
 intel is default VGA device

On Tue, Dec 17, 2013 at 10:17:24AM -0800, Keith Packard wrote:
> Chris Wilson <chris@...is-wilson.co.uk> writes:
> 
> > The bspec still says we must assert SR01 bit5 prior to disabling the VGA
> > plane.
> >
> > Perhaps the test should be whether (vga_reg & VGA_DISP_DISABLE) == 0 and
> > do nothing if the plane is already off.
> 
> The problem is that for some reason we're smashing *some other video
> card* when it's being used via efifb.

Ok, so as no vgaarb_clients have yet been registered and so the call to
grab the IO resource does not actually disable VGA IO routing to the
nvidia card.
 
> I'm wondering if vgaarb just doesn't work because efifb isn't telling
> vgaarb that it's using those registers (I mean, how would it even know?)

Agreed, that does seem to be the nub of the problem.
 
> The other simple option is to just not disable VGA if the card isn't
> primary; presumably it wasn't ever enabled.
> 
> And, yes, I know that the card probably won't work at all if it isn't
> primary because so much currently depends on the BIOS setting up bits of
> the card that we can't autodetect. So, another simple option would be to
> just refuse to load the driver if the card is secondary...

If you care to update the changelog to explain the problem is that
vgaarb is ineffective before all clients are registered, then I think
this is a good temporary hack. It should be possible for vgaarb to mark
resources as locked if the device is interpretting IO access and has no
method for disabling the IO grab (and then a vga_tryget() check here).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/