linux-kernel - Re: [git pull] drm request 3

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: <21d7e9971003041535g9dbfe46k67f64aa4219da0b8@mail.gmail.com>
Date:	Fri, 5 Mar 2010 09:35:12 +1000
From:	Dave Airlie <airlied@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Stephane Marchesin <stephane.marchesin@...il.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Dave Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org,
	dri-devel@...ts.sf.net
Subject: Re: [git pull] drm request 3

On Fri, Mar 5, 2010 at 9:28 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
>
> On Thu, 4 Mar 2010, Linus Torvalds wrote:
>>
>> Is it really just nouveau? I've not looked, but I bet the intel driver and
>> the radeon driver have _exactly_ the same "oh, I'm the wrong version, I
>> will now kill myself" behavior.
>
> Ok, I cloned the drm tree just to see, and it does seem like it's just
> nouveau that does that whole thing. At least from a quick grep of
> drmGetVersion() calls.
>
>> I certainly seem to remember some similar issues with the intel driver
>> long long ago.
>
> .. but Jesse tells me that it's using feature masks etc, so maybe my
> recollection is about unrelated issues.
>
> So yeah, nouveau seems to "special". Although somebody already said that
> if I'd have had a radeon, I'd have seen similar issues. Maybe the radeon
> driver just doesn't check the version number, and fails in different ways.
>

As I mentioned earlier we had one issue with i810 about 7-8 years ago, before
I was here, someone changed the i810_drm.h api incompatibly in XFree86.
This was one of the things that led to having a proper policy.

For radeon while we were developing the KMS feature in staging we
changed the API
once or twice, while we were developing KMS in Fedora we changed it at least
4 times, we shipped Intel KMS in F9 with a completly different API and
just dealt
with it, since upstreaming changed the API completely.

The staging API changes were mostly to fix things that userspace did
that made it
possible to trample over other X users memory. This meant you had to bump the
userspace that was doing the evil thing by mistake.

Once we removed KMS from staging, we stabilised all APIs and behaviour
(its not just the API, internal command stream checking for security issues).

Since then we made one change to the CS behaviour in a backwards compatible
manner so that old userspaces wouldn't die, but you couldn't abuse the
hole they had relied on.

I'm not saying it doesn't happen in other drivers from time to time,
but when it does
its treated as regression, for nouveau and STAGING that isn't what the Nouveau
project (which Stephane mostly speaks for) seems to want at this stage.

Dave.
--
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/