Exploit in 2.6 kernels

Exploit in 2.6 kernels

[John M Collins]

Please CC any reply to jmc AT xisl.com as I'm not subscribed - thanks

We had 5 machines broken into last night all but one with kernel 2.6.8
and found a binary "krad-no-longer-private.c" had  been downloaded

It contains the string:
 
k-rad.c - linux 2.6.* CPL 0 kernel exploit 
Discovered Jan 2005 by sd <sd@fucksheep.org>

If you want to look at it, I've copied it (with mode set to 444 of
course) to www.xisl.com/hack

Hope that is helpful

-- 
John Collins Xi Software Ltd www.xisl.com Tel: +44 (0)1707 886110
(Direct) +44 (0)7799 113162 (Mobile)

Re: Exploit in 2.6 kernels

[Baruch Even]

You can find the source at 
http://www.securiteam.com/exploits/5VP0N0UF5U.html

The fix: 
http://linux.bkbits.net:8080/linux-2.6/cset@422dd06a1p5PsyFhoGAJseinjEq3ew?nav=index.html|ChangeSet@-1d

CAN: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0736

John M Collins wrote:
> Please CC any reply to jmc AT xisl.com as I'm not subscribed - thanks
> 
> We had 5 machines broken into last night all but one with kernel 2.6.8
> and found a binary "krad-no-longer-private.c" had  been downloaded
> 
> It contains the string:
>  
> k-rad.c - linux 2.6.* CPL 0 kernel exploit 
> Discovered Jan 2005 by sd <sd@fucksheep.org>
> 
> If you want to look at it, I've copied it (with mode set to 444 of
> course) to www.xisl.com/hack
> 
> Hope that is helpful
> 

Re: Exploit in 2.6 kernels

[John M Collins]

Thanks to everyone for the pointers on this one I've rebuilt the kernels
and we'll see what happens.

Seems like they got in because on most of the machines I had an ancient
sshd_config which allowed Protocol 1. When I installed newer sshds the
newer sshd_config got stuck in as a ".rpmnew" file.

>From what I can make out the "visitor" was from Interbusiness.it if
anyone is interested.


John Collins Xi Software Ltd www.xisl.com Tel: +44 (0)1707 886110
(Direct) +44 (0)7799 113162 (Mobile)

Re: Exploit in 2.6 kernels

[Chris Wright]

* John M Collins (jmc@xisl.com) wrote:
> Thanks to everyone for the pointers on this one I've rebuilt the kernels
> and we'll see what happens.

BTW, I'd recommend updating to 2.6.11.7 so that you're protected from
another local root exploit.

thanks,
-chris

Re: Exploit in 2.6 kernels

[John M Collins]

On Tue, 2005-04-12 at 14:08 -0700, Chris Wright wrote:
> * John M Collins (jmc@xisl.com) wrote:
> > Thanks to everyone for the pointers on this one I've rebuilt the kernels
> > and we'll see what happens.
> 
> BTW, I'd recommend updating to 2.6.11.7 so that you're protected from
> another local root exploit.

I'll do that - trouble is round where I am they dish out Nvidia cards
like confetti, I've got them in the machine I use most and another 2 and
you have to do all that gyrating with running the script to FTP down and
build the secret module before you can run X. This is a big disincentive
when it comes to installing new kernels.

I wish some kind soul would speak nicely to Nvidia and get them to see
reason on the point but I suspect I'm not the first person to wish that.
(Or is there a sneaky way of patching the modules so they'll work in
another kernel without tainting it?).


John Collins Xi Software Ltd www.xisl.com Tel: +44 (0)1707 886110
(Direct) +44 (0)7799 113162 (Mobile)

Re: Exploit in 2.6 kernels

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 863 bytes --]

On Tue, 12 Apr 2005 22:32:59 BST, John M Collins said:

> I wish some kind soul would speak nicely to Nvidia and get them to see
> reason on the point but I suspect I'm not the first person to wish that.

NVidia is aware, and they're doing the best they can under the circumstances
(no, they can't opensource it all, there's other people's intellectual property
in there that they licensed...)

> (Or is there a sneaky way of patching the modules so they'll work in
> another kernel without tainting it?).

Patching it so it won't taint is a one-line patch.  However, it's so
morally bankrupt that I'm not giving any more hints.

Much trickier is doing it so the same module will insmod into multiple
kernels without screwing the pooch.  If you look around in nv-linux.h and
nv.c, there's a number of checks of KERNEL_VERSION, and they're all there
for a reason.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Exploit in 2.6 kernels

[Helge Hafting]

John M Collins wrote:

>On Tue, 2005-04-12 at 14:08 -0700, Chris Wright wrote:
>  
>
>>* John M Collins (jmc@xisl.com) wrote:
>>    
>>
>>>Thanks to everyone for the pointers on this one I've rebuilt the kernels
>>>and we'll see what happens.
>>>      
>>>
>>BTW, I'd recommend updating to 2.6.11.7 so that you're protected from
>>another local root exploit.
>>    
>>
>
>I'll do that - trouble is round where I am they dish out Nvidia cards
>like confetti, I've got them in the machine I use most and another 2 and
>you have to do all that gyrating with running the script to FTP down and
>build the secret module before you can run X. This is a big disincentive
>when it comes to installing new kernels.
>
>I wish some kind soul would speak nicely to Nvidia and get them to see
>reason on the point but I suspect I'm not the first person to wish that.
>  
>
You're not.  Complain to nvidia - using both email and snailmail.
If everybody with such problems did that, chances are they see
the light someday. Oh, and complain to the guy handing out
nvidia cards like confetti, state your preference for some other
card.  Perhaps that is easier to achieve.

>(Or is there a sneaky way of patching the modules so they'll work in
>another kernel without tainting it?).
>  
>
Whats wrong with tainting?  It is just a message, telling you that
the kernel is unsupported.  In this case because you're running a
closed-source module.  The tainting message itself does not do
anything bad.  There is a way - which is to write an open nvidia
driver.  To do that, you'll need to get the specs out of nvidia or
figure it out by reverse-engineering some other nvidia driver. Either
approach is hard, so people generally find it cheaper to just buy
a supported card.

Helge Hafting

Re: Exploit in 2.6 kernels

[Lennart Sorensen]

On Wed, Apr 13, 2005 at 11:47:46AM +0200, Helge Hafting wrote:
> You're not.  Complain to nvidia - using both email and snailmail.
> If everybody with such problems did that, chances are they see
> the light someday. Oh, and complain to the guy handing out
> nvidia cards like confetti, state your preference for some other
> card.  Perhaps that is easier to achieve.

What card would you recomend to people?

> Whats wrong with tainting?  It is just a message, telling you that
> the kernel is unsupported.  In this case because you're running a
> closed-source module.  The tainting message itself does not do
> anything bad.  There is a way - which is to write an open nvidia
> driver.  To do that, you'll need to get the specs out of nvidia or
> figure it out by reverse-engineering some other nvidia driver. Either
> approach is hard, so people generally find it cheaper to just buy
> a supported card.

It is becoming harder and harder to find supported cards it seems.
Finding a card with decent 2D drivers for X can still be done, but 3D is
just not really an option it seems.  Even 2D seems to be a problem on
many cards if you don't use a binary only driver.

Len Sorensen

Re: Exploit in 2.6 kernels

[Lars Marowsky-Bree]

On 2005-04-13T08:59:21, Lennart Sorensen <lsorense@csclub.uwaterloo.ca> wrote:

> It is becoming harder and harder to find supported cards it seems.
> Finding a card with decent 2D drivers for X can still be done, but 3D is
> just not really an option it seems.  Even 2D seems to be a problem on
> many cards if you don't use a binary only driver.

You are confusing the cause with the symptom.

Re: Exploit in 2.6 kernels

[Lennart Sorensen]

On Wed, Apr 13, 2005 at 03:06:46PM +0200, Lars Marowsky-Bree wrote:
> On 2005-04-13T08:59:21, Lennart Sorensen <lsorense@csclub.uwaterloo.ca> wrote:
> 
> > It is becoming harder and harder to find supported cards it seems.
> > Finding a card with decent 2D drivers for X can still be done, but 3D is
> > just not really an option it seems.  Even 2D seems to be a problem on
> > many cards if you don't use a binary only driver.
> 
> You are confusing the cause with the symptom.

Graphics card companies don't realize they are hardware companies not
software companies and that it is hardware they make their money from?
Oh and they have too many lawyers?

It seems to me that 2D graphics are a done deal, with no new inovation
taking place.  Releasing programing specs for that part should be a no
brainer.  If the nifty 3D routines are so important to keep secret from
the other guys then well keep those.  Release the 2D programing specs!

Len Sorensen

Re: Exploit in 2.6 kernels

[John M Collins]

On Wed, 2005-04-13 at 09:23 -0400, Lennart Sorensen wrote:

> Graphics card companies don't realize they are hardware companies not
> software companies and that it is hardware they make their money from?
> Oh and they have too many lawyers?
> 
> It seems to me that 2D graphics are a done deal, with no new inovation
> taking place.  Releasing programing specs for that part should be a no
> brainer.  If the nifty 3D routines are so important to keep secret from
> the other guys then well keep those.  Release the 2D programing specs!

Where I am (in the UK) you more or less have to buy computers in bits
and put them together if you want (like I do) to shuffle bits of
hardware between different machines to suit varying needs or bolt on
extra bits and pieces of new hardware and above all not pay M$ tax.

The nvidia card seems the only one with reasonable performance at a
reasonable price that fits on most motherboards that I can find.in these
parts.

> m-a is module-assistant which is used on debian to build a module

If I ask nicely can I download it from anywhere? I've just finished
building 2.6.11.7 and it might be nice to try it.

Could I possibly make a suggestion for "make xconfig" in the kernel tree
(and make other-kinds-of-config I suppose)?

I currently routinely copy the ".config" out of the previous kernel tree
before I start to save working through questions about sound cards I
never heard of and so forth.

Could it perhaps optionally initialise most of the settings to fit the
current machine and/or grab the last lot of settings
from /proc/config.gz?


John Collins Xi Software Ltd www.xisl.com Tel: +44 (0)1707 886110
(Direct) +44 (0)7799 113162 (Mobile)

Re: Exploit in 2.6 kernels

[Adrian Bunk]

On Wed, Apr 13, 2005 at 03:01:46PM +0100, John M Collins wrote:
>...
> Could I possibly make a suggestion for "make xconfig" in the kernel tree
> (and make other-kinds-of-config I suppose)?
> 
> I currently routinely copy the ".config" out of the previous kernel tree
> before I start to save working through questions about sound cards I
> never heard of and so forth.
> 
> Could it perhaps optionally initialise most of the settings to fit the
> current machine and/or grab the last lot of settings
> from /proc/config.gz?


  zcat /proc/config.gz > .config


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Exploit in 2.6 kernels

[Chris Friesen]

Lennart Sorensen wrote:

> Graphics card companies don't realize they are hardware companies not
> software companies and that it is hardware they make their money from?
> Oh and they have too many lawyers?

This has been mentioned before, but I'll say it again.

Nvidia has intellectual property from *other companies* in their 
drivers/hardware.

They are *not allowed* to make the specs public due to their agreements 
with those other companies.

It's that simple.

Chris

Re: Exploit in 2.6 kernels

[Helge Hafting]

Chris Friesen wrote:

> Lennart Sorensen wrote:
>
>> Graphics card companies don't realize they are hardware companies not
>> software companies and that it is hardware they make their money from?
>> Oh and they have too many lawyers?
>
>
> This has been mentioned before, but I'll say it again.
>
> Nvidia has intellectual property from *other companies* in their 
> drivers/hardware.
>
> They are *not allowed* to make the specs public due to their 
> agreements with those other companies.
>
> It's that simple.

That argument isn't very good.  It'd be quite bad if all the "intellectual
property" was Nvidia's own.  Then we'd complain that they could
simply release the specs instead of keeping them secret for no
good reason.

Of course my argument applies equally well when there is several
companies invloved.  Why can't they give us specs instead of keeping
them secret for no good reason???  The fact that nvidia isn't free
to do this _on their own_ doesn't change anything. The companies can
act together and release necessary information for the drm people.

Nvidia can, for example, tell their "ip"-partners that the specs is wanted
ant try to get a licence for handing out what's needed.  Or the other way
around - the "other companies" may want more sales of their stuff
and tell nvidia they want specs released to open-source developers. Or
simply release information about "their own" part of the card.

And for those that want to keep some things secret - they may not have 
to open
up all information - only enough to get a driver made.  For example:
"write this sequence of magic bytes to these registers in order to set
up some pipeline."  It tells how to get things done, but not every detail.
A driver based on such information might not be the best, but it
could possible be enough - and certainly better than nothing.

Helge Hafting

Re: nVidia stuff again

[Doug Ledford]

On Thu, 2005-04-14 at 16:01 +0200, Helge Hafting wrote:
>  instead of keeping them secret for no
> good reason.

But *that's* the point people keep ignoring: the specs for programming
the hardware, in some cases, reveals details about the hardware's
implementation that nVidia does *not* want to release (in addition to
suggesting their software tricks).  Why is it that people *assume* that
just the programming docs tells a person nothing about the hardware?  We
already know that knowing the registers of a card and what those
registers do tells you implicit information about the card's design and
also reveals implicit information about the design of software that
works with the card.  How complex the card's registers and programming
interface is determines how much you can infer, and the more RISC like
or simple the card is and the more that is handled in the driver, the
more obviously the design can be inferred just from the programming
specs.

The aic7xxx chips are a perfect example of this exact same thing.  If
you know how to program the registers on that card, then you know almost
everything about the hardware.  It's that simple (and that's a big part
of what makes it very fast, lots of room for driver optimizations and
enhanced feature support).

-- 
Doug Ledford <dledford@redhat.com>
http://people.redhat.com/dledford

Re: nVidia stuff again

[Dave Airlie]

> But *that's* the point people keep ignoring: the specs for programming
> the hardware, in some cases, reveals details about the hardware's
> implementation that nVidia does *not* want to release (in addition to
> suggesting their software tricks).  Why is it that people *assume* that
> just the programming docs tells a person nothing about the hardware?  We
> already know that knowing the registers of a card and what those
> registers do tells you implicit information about the card's design and
> also reveals implicit information about the design of software that
> works with the card.  How complex the card's registers and programming
> interface is determines how much you can infer, and the more RISC like
> or simple the card is and the more that is handled in the driver, the
> more obviously the design can be inferred just from the programming
> specs.

 I think the programming specs for a 3D graphics card can tell you
very little about it, the R200 specs are very good but I doubt anyone
would have a clue how to design the internals of the card just from
looking at them, and now that GPUs are getting more like CPUs in terms
of shaders and programming languages the specs are getting less and
less useful to tell what is actually going on....

The main reasons they don't like open source is from where I'm
standing, their IP lawyers and probably not being able to do sneaky
hacks in the driver because people can see them..

Dave.



> 
> The aic7xxx chips are a perfect example of this exact same thing.  If
> you know how to program the registers on that card, then you know almost
> everything about the hardware.  It's that simple (and that's a big part
> of what makes it very fast, lots of room for driver optimizations and
> enhanced feature support).
> 
> --
> Doug Ledford <dledford@redhat.com>
> http://people.redhat.com/dledford
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: nVidia stuff again

[Helge Hafting]

Dave Airlie wrote:

>The main reasons they don't like open source is from where I'm
>standing, their IP lawyers and probably not being able to do sneaky
>hacks in the driver because people can see them..
>
>  
>
Well . . . if *that* is a reason for disliking open source then the 
problem is solved.
We don't really need the source for their driver with the sneaky hacks 
exposed.
They could keep a proprietary driver with nasty hacks, and release a 
simplified
one (basically the same code with those hacks removed) along with the 
specs. 
Open source developers can then add their own hacks if need be.

Helge Hafting

Re: nVidia stuff again

[Doug Ledford]

On Thu, 2005-04-21 at 09:12 +1000, Dave Airlie wrote:
> > But *that's* the point people keep ignoring: the specs for programming
> > the hardware, in some cases, reveals details about the hardware's
> > implementation that nVidia does *not* want to release (in addition to
> > suggesting their software tricks).  Why is it that people *assume* that
> > just the programming docs tells a person nothing about the hardware?  We
> > already know that knowing the registers of a card and what those
> > registers do tells you implicit information about the card's design and
> > also reveals implicit information about the design of software that
> > works with the card.  How complex the card's registers and programming
> > interface is determines how much you can infer, and the more RISC like
> > or simple the card is and the more that is handled in the driver, the
> > more obviously the design can be inferred just from the programming
> > specs.
> 
>  I think the programming specs for a 3D graphics card can tell you
> very little about it, the R200 specs are very good but I doubt anyone
> would have a clue how to design the internals of the card just from
> looking at them, and now that GPUs are getting more like CPUs in terms
> of shaders and programming languages the specs are getting less and
> less useful to tell what is actually going on....

Ha!  That's the whole damn point Dave.  Use your head.  Just because ATI
is getting more complex with their GPU does *not* mean nVidia is.  Go
back to my original example of the aic7xxx cards.  The alternative to
their simple hardware design is something like the BusLogic or QLogic
cards that are far more complex.  Your assuming that because the ATI
cards are getting more complex and people are less able to discern their
makeup just by reading the specs that the nVidia cards are doing the
same, nVidia is telling you otherwise, and you are just blowing that off
as though you know more about their cards than they do.  Reality is that
they *could* be telling the truth and the fact that their card is a more
simplistic card than ATIs may be the very reason that ATI has ponied up
specs and they haven't.  Therefore, you can reliably discern absolutely
*zero* information about the nVidia cards from a reference to ATI specs.

> The main reasons they don't like open source is from where I'm
> standing, their IP lawyers and probably not being able to do sneaky
> hacks in the driver because people can see them..

"It's what you know, not what you think you know, that matters."  I
don't know why nVidia keeps their specs secret.  All I know is what they
tell the world.  But what I do know is that it's *possible* they could
be telling the truth, and I have no proof otherwise, regardless of any
suspicions.

-- 
Doug Ledford <dledford@redhat.com>
http://people.redhat.com/dledford

Re: nVidia stuff again

[Dave Airlie]

> 
> Ha!  That's the whole damn point Dave.  Use your head.  Just because ATI
> is getting more complex with their GPU does *not* mean nVidia is.  Go

No I rely on things I read from hardware review websites and from the
GPU manufacturers to wonder what they are doing, unless putting more
transistors onto their chips is making them less complex, both ATI and
Nvidia are implementing chips primarily to implement DirectX features
(the biggest market), this means they are both heading toward the same
thing, with 3D graphics doing things on the GPU vs doing them in the
driver is going to be quite noticable you end up doing as much as
possible in the hardware,  also things like SLI are certainly more
complex not less..

ATI are making their chips less "complex" from a programming point of
view, the R300 for example has no fixed-function pipelines, for modern
apps, the shader language is translated to the GPU by the driver, for
older apps using the fixed-function pipeline the driver emulates it on
top of the programmable interface..

what this comes down to in the end is that the register interfaces are
probably converging, there are only so many ways you can send
instructions to a GPU via DMA..

> specs and they haven't.  Therefore, you can reliably discern absolutely
> *zero* information about the nVidia cards from a reference to ATI specs.

But we have some lowlevel knowledge for the Nvidia cards as well.. not
detailed but you can pick directions from the presentations they make
and marketing literature they release....
 
> "It's what you know, not what you think you know, that matters."  I
> don't know why nVidia keeps their specs secret.  All I know is what they
> tell the world.  But what I do know is that it's *possible* they could
> be telling the truth, and I have no proof otherwise, regardless of any
> suspicions.

Well when previously asked for the specs by other developers the
answer before has been IP issues, it may not be totally true now, I
think now they just don't want to support open source because they
don't believe there is any money in it...

ATI didn't release full specs for r200 because they were being nice,
the Weather Channel said we won't use your chips unless we have an
open source driver and one can only persume proceeded to purchase a
lot of chips i.e. it made monetary sense to ATI at the time.. since
then it hasn't ...

The IP reasons come from the fact that the specs they did release
didn't contain any information on how to program a lot of ATI
proprietary features..

Also it is peculiar that ATI release 2D programming specs for their
newer cards and give support to the 2D ATI driver in X, Nvidia support
the 2D NV driver in X, why not the 3D?,
Intel won't give out specs for their latest chipsets but they do
provide an open source 2D and 3D driver via Tungsten Graphics...

I'm thinking of doing up a bit of a presentation for KS on 3D drivers
and the technical issues they bring to the kernel (without even
mentioning licensing and derived works..)

Dave.

Re: nVidia stuff again

[Lennart Sorensen]

On Thu, Apr 21, 2005 at 08:15:02AM -0400, Doug Ledford wrote:
> Ha!  That's the whole damn point Dave.  Use your head.  Just because ATI
> is getting more complex with their GPU does *not* mean nVidia is.  Go
> back to my original example of the aic7xxx cards.  The alternative to
> their simple hardware design is something like the BusLogic or QLogic
> cards that are far more complex.  Your assuming that because the ATI
> cards are getting more complex and people are less able to discern their
> makeup just by reading the specs that the nVidia cards are doing the
> same, nVidia is telling you otherwise, and you are just blowing that off
> as though you know more about their cards than they do.  Reality is that
> they *could* be telling the truth and the fact that their card is a more
> simplistic card than ATIs may be the very reason that ATI has ponied up
> specs and they haven't.  Therefore, you can reliably discern absolutely
> *zero* information about the nVidia cards from a reference to ATI specs.

Certainly possible.  Maybe all their real IP is in the code, although if
that was true, letting opensource peope ahve the programing spec and
have to do their own drivers wouldn't expose that IP.  I have no idea.

> "It's what you know, not what you think you know, that matters."  I
> don't know why nVidia keeps their specs secret.  All I know is what they
> tell the world.  But what I do know is that it's *possible* they could
> be telling the truth, and I have no proof otherwise, regardless of any
> suspicions.

At least as far as I have understood things, the 3D hardware in the old
SGIs was very simple.  Lots and lots of multiple and add units which the
drivers then used in clever ways to implement fast 3D.  nvidia certainly
employs many ex-SGI people, so perhaps internally it is still based on
that idea, although I doubt it's quite that simple anymore.

Len Sorensen

Re: nVidia stuff again

[Manu Abraham]

Lennart Sorensen wrote:
> On Thu, Apr 21, 2005 at 08:15:02AM -0400, Doug Ledford wrote:
> 
>>Ha!  That's the whole damn point Dave.  Use your head.  Just because ATI
>>is getting more complex with their GPU does *not* mean nVidia is.  Go
>>back to my original example of the aic7xxx cards.  The alternative to
>>their simple hardware design is something like the BusLogic or QLogic
>>cards that are far more complex.  Your assuming that because the ATI
>>cards are getting more complex and people are less able to discern their
>>makeup just by reading the specs that the nVidia cards are doing the
>>same, nVidia is telling you otherwise, and you are just blowing that off
>>as though you know more about their cards than they do.  Reality is that
>>they *could* be telling the truth and the fact that their card is a more
>>simplistic card than ATIs may be the very reason that ATI has ponied up
>>specs and they haven't.  Therefore, you can reliably discern absolutely
>>*zero* information about the nVidia cards from a reference to ATI specs.
> 
> 
> Certainly possible.  Maybe all their real IP is in the code, although if
> that was true, letting opensource peope ahve the programing spec and
> have to do their own drivers wouldn't expose that IP.  I have no idea.
> 

Even without opening up the code, but with programming specs there are 
many graphics driver guys out there, given the specs out it would not be 
too hard to have a decent driver, without the Nvidia IP. In that case 
there would be no question of IP violation.

Or maybe somebody can do a clean room implementation provided Nvidia 
agrees to some NDA, and the resultant work is acceptable to Nvidia 
provided that it is free of their IP.. Many hardware vendors do resort 
to these to get their hardware working properly under Linux, and in some 
cases, the Linux driver has proved to be a better driver than their 
Windows counterparts, albeit with lesser gimmicks/features.


Manu

Re: nVidia stuff again

[J.A. Magallon]

On 04.21, Manu Abraham wrote:
> Lennart Sorensen wrote:
> > On Thu, Apr 21, 2005 at 08:15:02AM -0400, Doug Ledford wrote:
> > 
> >>Ha!  That's the whole damn point Dave.  Use your head.  Just because ATI
> >>is getting more complex with their GPU does *not* mean nVidia is.  Go
> >>back to my original example of the aic7xxx cards.  The alternative to
> >>their simple hardware design is something like the BusLogic or QLogic
> >>cards that are far more complex.  Your assuming that because the ATI
> >>cards are getting more complex and people are less able to discern their
> >>makeup just by reading the specs that the nVidia cards are doing the
> >>same, nVidia is telling you otherwise, and you are just blowing that off
> >>as though you know more about their cards than they do.  Reality is that
> >>they *could* be telling the truth and the fact that their card is a more
> >>simplistic card than ATIs may be the very reason that ATI has ponied up
> >>specs and they haven't.  Therefore, you can reliably discern absolutely
> >>*zero* information about the nVidia cards from a reference to ATI specs.
> > 
> > 
> > Certainly possible.  Maybe all their real IP is in the code, although if
> > that was true, letting opensource peope ahve the programing spec and
> > have to do their own drivers wouldn't expose that IP.  I have no idea.
> > 
> 
> Even without opening up the code, but with programming specs there are 
> many graphics driver guys out there, given the specs out it would not be 
> too hard to have a decent driver, without the Nvidia IP. In that case 
> there would be no question of IP violation.
> 
> Or maybe somebody can do a clean room implementation provided Nvidia 
> agrees to some NDA, and the resultant work is acceptable to Nvidia 
> provided that it is free of their IP.. Many hardware vendors do resort 
> to these to get their hardware working properly under Linux, and in some 
> cases, the Linux driver has proved to be a better driver than their 
> Windows counterparts, albeit with lesser gimmicks/features.
> 

But the problem is like comparing CISC and RISC processors/code.
If you see the CISC assembler you do not see anything.
If you look at RISC code you can know many things about how the processor
pipelines are organized (you see interleaved float/int ops), you see how
much pipelines are there, what they do, and so on. Compare (hypothetically)
an ATI engine with 2 matrix-vector-multiply units and an nVidia with
8 dot product units. Perhaps ATI thought about doing matrices in parallel,
but never thought on doing rows in parallel. You could know that looking
at the code. Or at the programming specs ('load each row of your transform
in registers r0..r3 ....' )

I do not know how big are the ATI drivers, but looking at the nVidia ones,

werewolf:/lib/modules/2.6.11-jam14/kernel/drivers/video# ll
-rw-rw-r--  1 root root 4402072 Apr 14 23:18 nvidia.ko
werewolf:/usr/X11R6/lib# ll /usr/X11R6/lib/*7174*
-rwxr-xr-x  1 root root  485260 Apr 11 01:12 /usr/X11R6/lib/libGL.so.1.0.7174*
-rwxr-xr-x  1 root root 7626156 Apr 11 01:12 /usr/X11R6/lib/libGLcore.so.1.0.7174*

12 Mb of code is too much for a wrapper that just loads the hardware and
calls a rom ;) What is there ? Runtime loadable microcode ? Specially
optimized code for sending data to 2 pipes on a GeForce2 and 8 on a 6800 ?
Who knows. But sure the driver does _many_ things.

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.11-jam14 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk)) #5

Re: nVidia stuff again

[Arjan van de Ven]

> werewolf:/lib/modules/2.6.11-jam14/kernel/drivers/video# ll
> -rw-rw-r--  1 root root 4402072 Apr 14 23:18 nvidia.ko
> werewolf:/usr/X11R6/lib# ll /usr/X11R6/lib/*7174*
> -rwxr-xr-x  1 root root  485260 Apr 11 01:12 /usr/X11R6/lib/libGL.so.1.0.7174*
> -rwxr-xr-x  1 root root 7626156 Apr 11 01:12 /usr/X11R6/lib/libGLcore.so.1.0.7174*
> 
> 12 Mb of code is too much for a wrapper that just loads the hardware and
> calls a rom ;) What is there ? Runtime loadable microcode ? Specially
> optimized code for sending data to 2 pipes on a GeForce2 and 8 on a 6800 ?
> Who knows. But sure the driver does _many_ things.

this is because they put the entire openGL layer in the kernel (unlike
most open source drivers where the gl layer is in userspace and only the
hw part is in the kernel)

Re: Exploit in 2.6 kernels

[Alan Cox]

On Mer, 2005-04-13 at 14:23, Lennart Sorensen wrote:
> On Wed, Apr 13, 2005 at 03:06:46PM +0200, Lars Marowsky-Bree wrote:
> Graphics card companies don't realize they are hardware companies not
> software companies and that it is hardware they make their money from?
> Oh and they have too many lawyers?

Actually they are both. 3D performance is a combination of clever driver
technology -and- clever hardware. 

Alan

Re: Exploit in 2.6 kernels

[Dave Airlie]

On 4/16/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Mer, 2005-04-13 at 14:23, Lennart Sorensen wrote:
> > On Wed, Apr 13, 2005 at 03:06:46PM +0200, Lars Marowsky-Bree wrote:
> > Graphics card companies don't realize they are hardware companies not
> > software companies and that it is hardware they make their money from?
> > Oh and they have too many lawyers?
> 
> Actually they are both. 3D performance is a combination of clever driver
> technology -and- clever hardware.

Not to disagree too much, most of those "clever" driver technologies
are dirty hacks that boost performance in the quake/doom3 type
cases... but if they ever open sourced it those hardware review sites
would be over them like a bad rash...

I still don't think they would lose out by much.. I've just being
trying to RE the ATI Mpeg2 IDCT/MC hardware, ATI know this, I know
this, they are only wasting my time and my employers money (we still
are going to buy their chips... no choice..) will they give out specs
.. no .. why? cause of lawyers.. they use MPEG2 decoders for DVD
decode and some lawyer told them this is a major secret despite the
fact that everyone knows how to decode Mpeg2 and DVDs at this stage..

same story with VIA who persist on giving out a binary only blob for
MPEG2 hardware despite the fact that it was RE'ed over two years ago..
the secret is out...

Dave.

Re: Exploit in 2.6 kernels

[Duncan Sands]

> I still don't think they would lose out by much.. I've just being
> trying to RE the ATI Mpeg2 IDCT/MC hardware, ATI know this, I know
> this, they are only wasting my time and my employers money (we still
> are going to buy their chips... no choice..) will they give out specs
> .. no .. why? cause of lawyers.. they use MPEG2 decoders for DVD
> decode and some lawyer told them this is a major secret despite the
> fact that everyone knows how to decode Mpeg2 and DVDs at this stage..
> 
> same story with VIA who persist on giving out a binary only blob for
> MPEG2 hardware despite the fact that it was RE'ed over two years ago..
> the secret is out...

When I was RE the ATI IDCT stuff a few years ago, someone at ATI told
me that the problem was that the company they licensed the IDCT stuff
from wouldn't let them give out any specs.  I may be remembering this
wrong since it was a long time ago...

Duncan.

PS: At some point I changed hardware, and didn't need the IDCT anymore.
I just tried to find my notes on it, but there only seems to be some
stuff about the tv tuner...

Re: Exploit in 2.6 kernels

[Helge Hafting]

Lennart Sorensen wrote:

>On Wed, Apr 13, 2005 at 11:47:46AM +0200, Helge Hafting wrote:
>  
>
>>You're not.  Complain to nvidia - using both email and snailmail.
>>If everybody with such problems did that, chances are they see
>>the light someday. Oh, and complain to the guy handing out
>>nvidia cards like confetti, state your preference for some other
>>card.  Perhaps that is easier to achieve.
>>    
>>
>
>What card would you recomend to people?
>  
>
If all else fail - an *old* card.  This wasn't a problem before,
therefore it doesn't have to be now.  Unless you want to run
very new software that won't perform on those older cards.
Todays faster cpus may help though.

Look to http://dri.freedesktop.org/wiki/ for information about
which cards have open drivers and how well they work.
Some cards have specs available, others are reverse-engineered
to the extent that a driver have been written.

>  
>
>>Whats wrong with tainting?  It is just a message, telling you that
>>the kernel is unsupported.  In this case because you're running a
>>closed-source module.  The tainting message itself does not do
>>anything bad.  There is a way - which is to write an open nvidia
>>driver.  To do that, you'll need to get the specs out of nvidia or
>>figure it out by reverse-engineering some other nvidia driver. Either
>>approach is hard, so people generally find it cheaper to just buy
>>a supported card.
>>    
>>
>
>It is becoming harder and harder to find supported cards it seems.
>Finding a card with decent 2D drivers for X can still be done, but 3D is
>just not really an option it seems.  Even 2D seems to be a problem on
>many cards if you don't use a binary only driver.
>  
>
I have the impression that 2D is fine with ATI cards, even those
that doesn't have open 3D drivers.  And even a really old low-end
card performs fine for 2D work.  Even the unaccelerated
framebuffer drivers seems to have enough performance
for 2D in most cases. The cpu is fast these days. :-)

Helge Hafting

Re: Exploit in 2.6 kernels

[Olaf Titz]

> I have the impression that 2D is fine with ATI cards, even those
> that doesn't have open 3D drivers.  And even a really old low-end
> card performs fine for 2D work.  Even the unaccelerated
> framebuffer drivers seems to have enough performance
> for 2D in most cases. The cpu is fast these days. :-)

Not quite. The _perceived_ difference e.g. between unaccelerated fbdev
and mga driver is dramatic when you scroll around much in your windows
(of eclipse, mozilla...) even on 3 GHz CPUs. (I know very well since I
had to live with fbdev on a G550 for some time...)
And for video acceleration, there's always the point where it makes
the difference between stuttering and no stuttering.

I won't use any non-accelerated basic X11 and non-accelerated Xv any
more, no matter how fast the CPUs get. (The fact that it was always
worse n years ago for bigger n doesn't count...)

Olaf

PS. The most important feature of any graphics card for me? No fan.

Re: Exploit in 2.6 kernels

[Lennart Sorensen]

On Tue, Apr 12, 2005 at 10:32:59PM +0100, John M Collins wrote:
> I'll do that - trouble is round where I am they dish out Nvidia cards
> like confetti, I've got them in the machine I use most and another 2 and
> you have to do all that gyrating with running the script to FTP down and
> build the secret module before you can run X. This is a big disincentive
> when it comes to installing new kernels.
> 
> I wish some kind soul would speak nicely to Nvidia and get them to see
> reason on the point but I suspect I'm not the first person to wish that.
> (Or is there a sneaky way of patching the modules so they'll work in
> another kernel without tainting it?).

Well on my ssytem I can do something as simple as this in a script at
boot (before starting X) and it should nicely take care of it:

modprobe nvidia || m-a -t prepare nvidia && m-a -t build nvidia && m-a -t install nvidia && modprobe nvidia

Most likely I will have a working loaded nvidia driver at that point and
X will start successfully.

m-a is module-assistant which is used on debian to build a module
mathcing the running kernel (assuming it has access to either the source
of the running kernel or the headers of the running kernel) using the
sources from in this case nvidia-kernel-source package.  I don't know if
anything other than debian has anything like this, but it makes dealing
with nvidia's binary drivers fairly tolerable.

Len Sorensen

Re: Exploit in 2.6 kernels

[Eric Rannaud]

On Wed, 2005-04-13 at 09:02 -0400, Lennart Sorensen wrote:
> modprobe nvidia || m-a -t prepare nvidia && m-a -t build nvidia && m-a -t install nvidia && modprobe nvidia

Something along the lines of:
modprobe nvidia || sh NVIDIA-Linux-x86-1.0-6629-pkg1.run -s -f --no-network && modprobe nvidia

should work on any distribution (it runs NVIDIA installer silently).
(see sh NVIDIA-Linux-x86-1.0-6629-pkg1.run --advanced-options)

    /er.
-- 
http://www.eleves.ens.fr/home/rannaud/

Re: Exploit in 2.6 kernels

[Lennart Sorensen]

On Wed, Apr 13, 2005 at 09:26:28AM -0500, Eric Rannaud wrote:
> On Wed, 2005-04-13 at 09:02 -0400, Lennart Sorensen wrote:
> > modprobe nvidia || m-a -t prepare nvidia && m-a -t build nvidia && m-a -t install nvidia && modprobe nvidia
> 
> Something along the lines of:
> modprobe nvidia || sh NVIDIA-Linux-x86-1.0-6629-pkg1.run -s -f --no-network && modprobe nvidia
> 
> should work on any distribution (it runs NVIDIA installer silently).
> (see sh NVIDIA-Linux-x86-1.0-6629-pkg1.run --advanced-options)

It will work on most.  Some don't like where the nvidia installer dumps
it files in some cases.  Certainly doesn't work on every amd64 system
since they can't agree where 64bit libs should go yet.

It also violates my principles more than using binary only drivers does.
All files in /usr (except /usr/local) _must_ be installed by one package
management tool.  No excaptions allowed.  I haven't had to reinstall for
6 years, so I am sticking with my principles.

Len Sorensen

Re: Exploit in 2.6 kernels

[Greg Folkert]

[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]

On Wed, 2005-04-13 at 10:41 -0400, Lennart Sorensen wrote:
> On Wed, Apr 13, 2005 at 09:26:28AM -0500, Eric Rannaud wrote:
> > On Wed, 2005-04-13 at 09:02 -0400, Lennart Sorensen wrote:
> > > modprobe nvidia || m-a -t prepare nvidia && m-a -t build nvidia && m-a -t install nvidia && modprobe nvidia
> > 
> > Something along the lines of:
> > modprobe nvidia || sh NVIDIA-Linux-x86-1.0-6629-pkg1.run -s -f --no-network && modprobe nvidia
> > 
> > should work on any distribution (it runs NVIDIA installer silently).
> > (see sh NVIDIA-Linux-x86-1.0-6629-pkg1.run --advanced-options)
> 
> It will work on most.  Some don't like where the nvidia installer dumps
> it files in some cases.  Certainly doesn't work on every amd64 system
> since they can't agree where 64bit libs should go yet.
> 
> It also violates my principles more than using binary only drivers does.
> All files in /usr (except /usr/local) _must_ be installed by one package
> management tool.  No excaptions allowed.  I haven't had to reinstall for
> 6 years, so I am sticking with my principles.

A-Freakin'-MEN me droogy.

Hehehe, either a slow system, or you know how to transfer a working
setup to another machine.

My current image I use(d) for all of my machines was Built a long time
ago, I think slink was what I used to build it. On a Pentium-90.

Currently on an Athlon XP3200+ with bells and whistles not even thought
of then. Moved through about 12 machines since the beginning.
-- 
greg, greg@gregfolkert.net

The technology that is
Stronger, better, faster: Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Exploit in 2.6 kernels

[John M Collins]

On Thu, 2005-04-14 at 16:02 -0400, Greg Folkert wrote:
> A-Freakin'-MEN me droogy.
> 
> Hehehe, either a slow system, or you know how to transfer a working
> setup to another machine.
> 
> My current image I use(d) for all of my machines was Built a long time
> ago, I think slink was what I used to build it. On a Pentium-90.
> 
> Currently on an Athlon XP3200+ with bells and whistles not even thought
> of then. Moved through about 12 machines since the beginning.

Just to say thanks again for your help - got 2.6.11.7 going everywhere
without hitches. Of course I just called the kernels 2.6.11.7 everywhere
so one version of the nvidia module fitted all.

I also stuck it on a Dell laptop I've got - a Latitude 100L - and at
last I've got ACPI working so I can see the battery level before it
dies.

Maybe our "visitor" did us a favour. (Sort of).

-- 
John Collins Xi Software Ltd www.xisl.com Tel: +44 (0)1707 886110
(Direct) +44 (0)7799 113162 (Mobile)

Re: Exploit in 2.6 kernels

[Alessandro Salvatori]

[-- Attachment #1: Type: text/plain, Size: 392 bytes --]

On Tue, 12 Apr 2005 16:00:34 +0100
John M Collins <jmc@xisl.com> wrote:
> >From what I can make out the "visitor" was from Interbusiness.it if
> anyone is interested.

it is as meaningful as telling that you had visits from italy...
interbusiness is the main commercial italian backbone afaik... most
telecom italia's adsl users have a reverse .interbusiness.it

cheers
alessandro

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]