[opensuse] latest kernel update breaks ATI binary driver
Hi all, just a heads up. If you use the ATI binary driver, and install the latest kernel update (2.6.34.7-0.3), then you will no longer be able to recompile the ATI driver due to missing compat_alloc_user_space() symbol in fglrx/kcl_ioctl.c. According to http://www.gossamer-threads.com/lists/linux/kernel/1277377, the "compat_alloc_user_space()" symbol became GPL-only, got moved to another header, etc. Personally, I find it unbelievable that openSUSE kernel team would release a minor kernel upgrade that would screw up all users of the ATI binary driver. -- Regards, Vadym -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 23 September 2010, Vadym Krevs wrote:
Hi all,
just a heads up. If you use the ATI binary driver, and install the latest kernel update (2.6.34.7-0.3), then you will no longer be able to recompile the ATI driver due to missing compat_alloc_user_space() symbol in fglrx/kcl_ioctl.c.
According to http://www.gossamer-threads.com/lists/linux/kernel/1277377, the "compat_alloc_user_space()" symbol became GPL-only, got moved to another header, etc.
Personally, I find it unbelievable that openSUSE kernel team would release a minor kernel upgrade that would screw up all users of the ATI binary driver.
I don't think there was much of a choice, since upstream decided to license the new function "GPl only". Distributions can change things in open source code, but as far as I know only BSD style licenses allow relicensing. FYI there is a patch for the ATI driver Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 23/09/10 22:18, Anders Johansson wrote:
Hi all,
just a heads up. If you use the ATI binary driver, and install the latest kernel update (2.6.34.7-0.3), then you will no longer be able to recompile the ATI driver due to missing compat_alloc_user_space() symbol in fglrx/kcl_ioctl.c.
According to http://www.gossamer-threads.com/lists/linux/kernel/1277377, the "compat_alloc_user_space()" symbol became GPL-only, got moved to another header, etc.
Personally, I find it unbelievable that openSUSE kernel team would release a minor kernel upgrade that would screw up all users of the ATI binary driver. I don't think there was much of a choice, since upstream decided to license
On Thursday 23 September 2010, Vadym Krevs wrote: the new function "GPl only". Distributions can change things in open source code, but as far as I know only BSD style licenses allow relicensing.
FYI there is a patch for the ATI driver
Anders IMHO, this could have been handled differently. E.g., the updated kernel could have been released once an updated ATI driver was available.
As to a patch - well, it is easy to find and apply, if you're a software engineer like myself. What about the average Joe user ... So much for the strategy statement: "The target users of the openSUSE distribution are people who need to get work done and want something *stable* and usable for their every day needs." -- Regards, Vadym -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 9/23/2010 2:39 PM, Vadym Krevs wrote:
On 23/09/10 22:18, Anders Johansson wrote:
Hi all,
just a heads up. If you use the ATI binary driver, and install the latest kernel update (2.6.34.7-0.3), then you will no longer be able to recompile the ATI driver due to missing compat_alloc_user_space() symbol in fglrx/kcl_ioctl.c.
According to http://www.gossamer-threads.com/lists/linux/kernel/1277377, the "compat_alloc_user_space()" symbol became GPL-only, got moved to another header, etc.
Personally, I find it unbelievable that openSUSE kernel team would release a minor kernel upgrade that would screw up all users of the ATI binary driver. I don't think there was much of a choice, since upstream decided to license
On Thursday 23 September 2010, Vadym Krevs wrote: the new function "GPl only". Distributions can change things in open source code, but as far as I know only BSD style licenses allow relicensing.
FYI there is a patch for the ATI driver
Anders IMHO, this could have been handled differently. E.g., the updated kernel could have been released once an updated ATI driver was available.
As to a patch - well, it is easy to find and apply, if you're a software engineer like myself. What about the average Joe user ... So much for the strategy statement: "The target users of the openSUSE distribution are people who need to get work done and want something *stable* and usable for their every day needs."
Except some of those ATI drivers will never be updated, because the cards in question are long out of production, but still in wide use. The opensource drivers are no where near capable enough yet. You can't really patch the binary drivers. -- _____________________________________ At one time I had a Real Sig. Its been downsized. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 23 September 2010, Vadym Krevs wrote:
IMHO, this could have been handled differently. E.g., the updated kernel could have been released once an updated ATI driver was available.
As to a patch - well, it is easy to find and apply, if you're a software engineer like myself. What about the average Joe user ... So much for the strategy statement: "The target users of the openSUSE distribution are people who need to get work done and want something *stable* and usable for their every day needs."
"Joe user" would use the pre-built packages. From what I understand, they will continue working without needing a recompile, since the affected function was an inline function before, so the code is already inside the driver. As far as I know it will continue working without needing any change (but I don't currently have any ATI cards, so I can't back this up from personal experience, it is just what I have heard reported). Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 9/23/2010 2:55 PM, Anders Johansson wrote:
On Thursday 23 September 2010, Vadym Krevs wrote:
IMHO, this could have been handled differently. E.g., the updated kernel could have been released once an updated ATI driver was available.
As to a patch - well, it is easy to find and apply, if you're a software engineer like myself. What about the average Joe user ... So much for the strategy statement: "The target users of the openSUSE distribution are people who need to get work done and want something *stable* and usable for their every day needs."
"Joe user" would use the pre-built packages. From what I understand, they will continue working without needing a recompile, since the affected function was an inline function before, so the code is already inside the driver. As far as I know it will continue working without needing any change (but I don't currently have any ATI cards, so I can't back this up from personal experience, it is just what I have heard reported).
Anders
The prebuilt ATI packages wont install either Anders. That leaves you with their Driver Loader packages. The driver loader package ATI distributes builds drivers on the fly and it fails too. If I roll back one kernel, it will (maybe) build. Joe user would be stuck using the open source drivers and forgo compositing and run it as a 2D card. (Grousing all the while). -- _____________________________________ At one time I had a Real Sig. Its been downsized. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thu, Sep 23, 2010 at 03:06:52PM -0700, John Andersen wrote:
On 9/23/2010 2:55 PM, Anders Johansson wrote:
On Thursday 23 September 2010, Vadym Krevs wrote:
IMHO, this could have been handled differently. E.g., the updated kernel could have been released once an updated ATI driver was available.
As to a patch - well, it is easy to find and apply, if you're a software engineer like myself. What about the average Joe user ... So much for the strategy statement: "The target users of the openSUSE distribution are people who need to get work done and want something *stable* and usable for their every day needs."
"Joe user" would use the pre-built packages. From what I understand, they will continue working without needing a recompile, since the affected function was an inline function before, so the code is already inside the driver. As far as I know it will continue working without needing any change (but I don't currently have any ATI cards, so I can't back this up from personal experience, it is just what I have heard reported).
Anders
The prebuilt ATI packages wont install either Anders.
Really? WHat is the error?
That leaves you with their Driver Loader packages. The driver loader package ATI distributes builds drivers on the fly and it fails too. If I roll back one kernel, it will (maybe) build.
Joe user would be stuck using the open source drivers and forgo compositing and run it as a 2D card. (Grousing all the while).
We figured and tested that the existing driver would still work, but apparently this did not apply to all cases. AMD/ATI also has a patch for the issue to their driver. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 09/23/2010 03:08 PM, Marcus Meissner wrote:
On Thu, Sep 23, 2010 at 03:06:52PM -0700, John Andersen wrote:
On 9/23/2010 2:55 PM, Anders Johansson wrote:
On Thursday 23 September 2010, Vadym Krevs wrote:
IMHO, this could have been handled differently. E.g., the updated kernel could have been released once an updated ATI driver was available.
As to a patch - well, it is easy to find and apply, if you're a software engineer like myself. What about the average Joe user ... So much for the strategy statement: "The target users of the openSUSE distribution are people who need to get work done and want something *stable* and usable for their every day needs."
"Joe user" would use the pre-built packages. From what I understand, they will continue working without needing a recompile, since the affected function was an inline function before, so the code is already inside the driver. As far as I know it will continue working without needing any change (but I don't currently have any ATI cards, so I can't back this up from personal experience, it is just what I have heard reported).
Anders
The prebuilt ATI packages wont install either Anders.
Really? WHat is the error?
That leaves you with their Driver Loader packages. The driver loader package ATI distributes builds drivers on the fly and it fails too. If I roll back one kernel, it will (maybe) build.
Joe user would be stuck using the open source drivers and forgo compositing and run it as a 2D card. (Grousing all the while).
We figured and tested that the existing driver would still work, but apparently this did not apply to all cases.
AMD/ATI also has a patch for the issue to their driver.
Ciao, Marcus
I can't speak to all cards, but in my case their driver does not exist for my Mobility Radeon x1400 card any more and I had to use their package to built RPMs and then install those for the last several versions of opensuse. See this ARchives thread of yesterday: http://linux.derkeiler.com/Mailing-Lists/SuSE/2010-09/msg01430.html I can't go to AMD and download anything. masterpatricko site, quoted in above archive message works for 2.6.33 but not 34. The ATI repository has nothing for my card. See http://en.opensuse.org/SDB:ATI_drivers -- Explain again the part about rm -rf / -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday 24 September 2010, jsa wrote:
I can't speak to all cards, but in my case their driver does not exist for my Mobility Radeon x1400 card any more and I had to use their package to built RPMs and then install those for the last several versions of opensuse.
Well, this wouldn't affect the prebuilt package's ability to install
See this ARchives thread of yesterday: http://linux.derkeiler.com/Mailing-Lists/SuSE/2010-09/msg01430.html
I can't go to AMD and download anything. masterpatricko site, quoted in above archive message works for 2.6.33 but not 34.
The module you built for the pre-update kernel should work with the latest kernel as well. Just copy over the module. If it doesn't, you'll have to apply the patch from ATI Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 9/23/2010 3:30 PM, Anders Johansson wrote:
On Friday 24 September 2010, jsa wrote:
I can't speak to all cards, but in my case their driver does not exist for my Mobility Radeon x1400 card any more and I had to use their package to built RPMs and then install those for the last several versions of opensuse.
Well, this wouldn't affect the prebuilt package's ability to install
See this ARchives thread of yesterday: http://linux.derkeiler.com/Mailing-Lists/SuSE/2010-09/msg01430.html
I can't go to AMD and download anything. masterpatricko site, quoted in above archive message works for 2.6.33 but not 34.
The module you built for the pre-update kernel should work with the latest kernel as well. Just copy over the module.
If it doesn't, you'll have to apply the patch from ATI
Where is that patch? -- _____________________________________ At one time I had a Real Sig. Its been downsized. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday 24 September 2010, John Andersen wrote:
On 9/23/2010 3:30 PM, Anders Johansson wrote:
On Friday 24 September 2010, jsa wrote:
I can't speak to all cards, but in my case their driver does not exist for my Mobility Radeon x1400 card any more and I had to use their package to built RPMs and then install those for the last several versions of opensuse.
Well, this wouldn't affect the prebuilt package's ability to install
See this ARchives thread of yesterday: http://linux.derkeiler.com/Mailing-Lists/SuSE/2010-09/msg01430.html
I can't go to AMD and download anything. masterpatricko site, quoted in above archive message works for 2.6.33 but not 34.
The module you built for the pre-update kernel should work with the latest kernel as well. Just copy over the module.
If it doesn't, you'll have to apply the patch from ATI
Where is that patch?
There are a few floating around the net. This is from bugzilla. This is for the file kcl_ioctl.c - return compat_alloc_user_space(size); + void __user *ret = arch_compat_alloc_user_space(size); + + /* prevent stack overflow */ + if (!access_ok(VERIFY_WRITE, ret, size)) + return NULL; + + return (void *)ret; How this actually applies to the version you have I couldn't say since I don't have it. It should be easy to do though Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 09/23/2010 05:24 PM, jsa wrote:
I can't speak to all cards, but in my case their driver does not exist for my Mobility Radeon x1400 card any more and I had to use their package to built RPMs and then install those for the last several versions of opensuse.
See this ARchives thread of yesterday: http://linux.derkeiler.com/Mailing-Lists/SuSE/2010-09/msg01430.html
I can't go to AMD and download anything. masterpatricko site, quoted in above archive message works for 2.6.33 but not 34.
This a well know and unfortunate issue that I raised on the factory list in April '09, well before 11.2 was released. See: [opensuse-factory] Plans and Issues for ATI fglrx Driver for 11.2? http://lists.opensuse.org/opensuse-factory/2009-04/msg00063.html (there are some 30-40 replies) It is the direct result of a decision made by AMD/ATI to *screw* all of their existing customers with pre-2400 series graphics card by discontinuing all Linux driver support in March 2009. (many of those in laptops less than 18 months old at the time) All pre-2400 series card suddenly became "Legacy Cards" The 9-3 driver is the last driver to support pre-2400 series cards and supports nothing past xorg 7.4. The only "legacy" drivers to support 11.1 (xorg 7.4) were the 10-8 through 9-3 drivers and 10-8 through 9-2 would cause my box with a RS690M (x1250) card to spontaneously reboot on xdm start. The 9.3 driver gave roughly 50% the performance the 8-9 driver did. I don't know the technical reason why somebody much smarter than I am can't make the fglrx driver build on later versions, but I can tell you many smart people have looked at the issue and we still have no driver option for pre-2400 series cards post 11.1. Bottom line for legacy cards is if you are lucky enough to have an RS6xx card, the radeonhd driver offers some advantages over the radeon driver. The bad news is performance and heat load issue suck compared to the fglrx driver. So if you need graphics performance with recent releases or distros - it's new laptop time. Always remember the corporate good-will AMD showed all it existing customers when it dropped Linux support for them and re-branded their cards "Legacy Cards". Burn me once, shame on you, burn me twice shame on me --> Buy nvidia or intel gpus from now on. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
John Andersen wrote: [snip]
"Joe user" would use the pre-built packages. From what I understand, they will continue working without needing a recompile, since the affected function was an inline function before, so the code is already inside the driver. As far as I know it will continue working without needing any change (but I don't currently have any ATI cards, so I can't back this up from personal experience, it is just what I have heard reported).
Anders
The prebuilt ATI packages wont install either Anders. That leaves you with their Driver Loader packages. The driver loader package ATI distributes builds drivers on the fly and it fails too. If I roll back one kernel, it will (maybe) build.
Currently using what they call Catalyst 10.9 on 2.6.34.7-0.2-desktop. It builds and works, though I see it as a regression. Drag a window and it smears really bad and there are some artifacts affecting scrolling in Kontact and Konsole that I've seen so far. Killing the app when this happens and restarting it usually makes things good again. 10.9 is very noticeably slower than 10.8. Think I will go back to 10.8 until next month.
Joe user would be stuck using the open source drivers and forgo compositing and run it as a 2D card. (Grousing all the while).
Just using the HD 3300 onboard IGP at this point to examine ATI's Linux support. While the drivers have received increasing amounts of effort on ATI's part my particular bone to pick is this: I can have either 3D acceleration or Xinerama dual monitors, but not both. Nvidia's TwinView provides both. So for me it's looking more and more like ATI is out; the next card will be Nvidia. -Mike -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 9/23/2010 3:39 PM, Michael Powell wrote:
John Andersen wrote:
[snip]
"Joe user" would use the pre-built packages. From what I understand, they will continue working without needing a recompile, since the affected function was an inline function before, so the code is already inside the driver. As far as I know it will continue working without needing any change (but I don't currently have any ATI cards, so I can't back this up from personal experience, it is just what I have heard reported).
Anders
The prebuilt ATI packages wont install either Anders. That leaves you with their Driver Loader packages. The driver loader package ATI distributes builds drivers on the fly and it fails too. If I roll back one kernel, it will (maybe) build.
Currently using what they call Catalyst 10.9 on 2.6.34.7-0.2-desktop. It builds and works, though I see it as a regression. Drag a window and it smears really bad and there are some artifacts affecting scrolling in Kontact and Konsole that I've seen so far. Killing the app when this happens and restarting it usually makes things good again. 10.9 is very noticeably slower than 10.8. Think I will go back to 10.8 until next month.
Thats probably because it silently "fell back to something horrible" as Lew Wolfgang so eloquently put it. Its probably loaded Mesa at that point and you are not using what you think you are using. -- _____________________________________ At one time I had a Real Sig. Its been downsized. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
John Andersen wrote:
On 9/23/2010 3:39 PM, Michael Powell wrote:
John Andersen wrote:
[snip]
"Joe user" would use the pre-built packages. From what I understand, they will continue working without needing a recompile, since the affected function was an inline function before, so the code is already inside the driver. As far as I know it will continue working without needing any change (but I don't currently have any ATI cards, so I can't back this up from personal experience, it is just what I have heard reported).
Anders
The prebuilt ATI packages wont install either Anders. That leaves you with their Driver Loader packages. The driver loader package ATI distributes builds drivers on the fly and it fails too. If I roll back one kernel, it will (maybe) build.
Currently using what they call Catalyst 10.9 on 2.6.34.7-0.2-desktop. It builds and works, though I see it as a regression. Drag a window and it smears really bad and there are some artifacts affecting scrolling in Kontact and Konsole that I've seen so far. Killing the app when this happens and restarting it usually makes things good again. 10.9 is very noticeably slower than 10.8. Think I will go back to 10.8 until next month.
Thats probably because it silently "fell back to something horrible" as Lew Wolfgang so eloquently put it. Its probably loaded Mesa at that point and you are not using what you think you are using.
That sounds right to me. Now where did I hide that 10.8 file from month ago... As soon as I find it I'm going back to 10.8 for a while. -Mike -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 09/23/2010 04:39 PM, Vadym Krevs wrote:
IMHO, this could have been handled differently. E.g., the updated kernel could have been released once an updated ATI driver was available.
As to a patch - well, it is easy to find and apply, if you're a software engineer like myself. What about the average Joe user ... So much for the strategy statement: "The target users of the openSUSE distribution are people who need to get work done and want something *stable* and usable for their every day needs."
God, this guy sounds like Rankin :p Vadym - just remember you catch more flies with honey than you do salt ;-) -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* David C. Rankin <drankinatty@suddenlinkmail.com> [09-23-10 18:15]:
On 09/23/2010 04:39 PM, Vadym Krevs wrote:
IMHO, this could have been handled differently. E.g., the updated kernel could have been released once an updated ATI driver was available.
As to a patch - well, it is easy to find and apply, if you're a software engineer like myself. What about the average Joe user ... So much for the strategy statement: "The target users of the openSUSE distribution are people who need to get work done and want something *stable* and usable for their every day needs."
God, this guy sounds like Rankin :p
Vadym - just remember you catch more flies with honey than you do salt ;-)
Perhaps a bit more subtle, ie: less sledge-hammer effect :^) AND, when did you worry about catching flies? -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 23 September 2010 23:39:08 Vadym Krevs wrote:
Personally, I find it unbelievable that openSUSE kernel team would release a minor kernel upgrade that would screw up all users of the ATI binary driver.
IMHO, this could have been handled differently. E.g., the updated kernel could have been released once an updated ATI driver was available.
This kernel update fixed a serious security issue, you would have people with vulnerable systems wait for a fix to proprietary graphics drivers before they could have secure systems?
As to a patch - well, it is easy to find and apply, if you're a software engineer like myself. What about the average Joe user ... So much for the strategy statement: "The target users of the openSUSE distribution are people who need to get work done and want something *stable* and usable for their every day needs."
Do the open source drivers work with this kernel update? If so, I don't think it's reasonable to use proprietary drivers then complain about them breaking. I don't want to turn this into a pissing contest, but I thought it was generally accepted that if you are prepared to use proprietary drivers, and want some semblance of driver stability, then using an Nvidia card on Linux was the sane thing to do? -- “What can be asserted without proof can be dismissed without proof.” - Christopher Hitchens -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 09/23/2010 05:43 PM, Graham Anderson wrote:
On Thursday 23 September 2010 23:39:08 Vadym Krevs wrote:
Personally, I find it unbelievable that openSUSE kernel team would release a minor kernel upgrade that would screw up all users of the ATI binary driver. IMHO, this could have been handled differently. E.g., the updated kernel could have been released once an updated ATI driver was available. This kernel update fixed a serious security issue, you would have people with vulnerable systems wait for a fix to proprietary graphics drivers before they could have secure systems?
As to a patch - well, it is easy to find and apply, if you're a software engineer like myself. What about the average Joe user ... So much for the strategy statement: "The target users of the openSUSE distribution are people who need to get work done and want something *stable* and usable for their every day needs." Do the open source drivers work with this kernel update?
No.
I don't want to turn this into a pissing contest, but I thought it was generally accepted that if you are prepared to use proprietary drivers, and want some semblance of driver stability, then using an Nvidia card on Linux was the sane thing to do?
Unfortunately users don't always have the choice to choose Nvidia. In my case, my employer provided a desktop with an embedded ATI Radeon HD 3450. I can live with miserable GUI performance, or I can purchase Nvidia with my own funds, or I can load Win-7. I think I'll take the use-my-own-money route, but it is a frustrating situation nevertheless. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thu, Sep 23, 2010 at 17:39, Vadym Krevs <vkrevs@serena.com> wrote:
On 23/09/10 22:18, Anders Johansson wrote:
On Thursday 23 September 2010, Vadym Krevs wrote:
Hi all,
just a heads up. If you use the ATI binary driver, and install the latest kernel update (2.6.34.7-0.3), then you will no longer be able to recompile the ATI driver due to missing compat_alloc_user_space() symbol in fglrx/kcl_ioctl.c.
According to http://www.gossamer-threads.com/lists/linux/kernel/1277377, the "compat_alloc_user_space()" symbol became GPL-only, got moved to another header, etc.
Personally, I find it unbelievable that openSUSE kernel team would release a minor kernel upgrade that would screw up all users of the ATI binary driver.
I don't think there was much of a choice, since upstream decided to license the new function "GPl only". Distributions can change things in open source code, but as far as I know only BSD style licenses allow relicensing.
FYI there is a patch for the ATI driver
Anders
IMHO, this could have been handled differently. E.g., the updated kernel could have been released once an updated ATI driver was available.
As to a patch - well, it is easy to find and apply, if you're a software engineer like myself. What about the average Joe user ... So much for the strategy statement: "The target users of the openSUSE distribution are people who need to get work done and want something *stable* and usable for their every day needs."
So why are these shenanigans from upstream allowed into openSUSE? Why not disable the useless GPL only code in the Kernel as it serves no real technical purpose, it adds nothing but bloat to the Kernel. What ever happened to "free as in freedom?" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 09/23/2010 09:27 PM, Andrew Joakimsen wrote:
On Thu, Sep 23, 2010 at 17:39, Vadym Krevs<vkrevs@serena.com> wrote:
On 23/09/10 22:18, Anders Johansson wrote:
On Thursday 23 September 2010, Vadym Krevs wrote:
Hi all,
just a heads up. If you use the ATI binary driver, and install the latest kernel update (2.6.34.7-0.3), then you will no longer be able to recompile the ATI driver due to missing compat_alloc_user_space() symbol in fglrx/kcl_ioctl.c.
According to http://www.gossamer-threads.com/lists/linux/kernel/1277377, the "compat_alloc_user_space()" symbol became GPL-only, got moved to another header, etc.
Personally, I find it unbelievable that openSUSE kernel team would release a minor kernel upgrade that would screw up all users of the ATI binary driver.
I don't think there was much of a choice, since upstream decided to license the new function "GPl only". Distributions can change things in open source code, but as far as I know only BSD style licenses allow relicensing.
FYI there is a patch for the ATI driver
Anders
IMHO, this could have been handled differently. E.g., the updated kernel could have been released once an updated ATI driver was available.
As to a patch - well, it is easy to find and apply, if you're a software engineer like myself. What about the average Joe user ... So much for the strategy statement: "The target users of the openSUSE distribution are people who need to get work done and want something *stable* and usable for their every day needs."
So why are these shenanigans from upstream allowed into openSUSE? Why not disable the useless GPL only code in the Kernel as it serves no real technical purpose, it adds nothing but bloat to the Kernel. What ever happened to "free as in freedom?"
It serves no purpose other than to fix a widely exploitable root hole. We have tests in place to ensure that the kABI doesn't change between releases, and it hasn't. The API has and that had unforseen consequences. As other people have noted, getting a quick fix out for a root exploit trumps ensuring that a proprietary driver still builds. And the module built against the last kernel still works, but still has the exploit. We chose to keep the change rather than work around it since ATI had already developed a fix (and they had to, since the upstream commit wasn't going to change to accommodate them). -Jeff -- Jeff Mahoney SUSE Labs -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, Sep 24, 2010 at 12:07, Jeff Mahoney <jeffm@suse.com> wrote:
On 09/23/2010 09:27 PM, Andrew Joakimsen wrote:
On Thu, Sep 23, 2010 at 17:39, Vadym Krevs<vkrevs@serena.com> wrote:
On 23/09/10 22:18, Anders Johansson wrote:
On Thursday 23 September 2010, Vadym Krevs wrote:
Hi all,
just a heads up. If you use the ATI binary driver, and install the latest kernel update (2.6.34.7-0.3), then you will no longer be able to recompile the ATI driver due to missing compat_alloc_user_space() symbol in fglrx/kcl_ioctl.c.
According to http://www.gossamer-threads.com/lists/linux/kernel/1277377, the "compat_alloc_user_space()" symbol became GPL-only, got moved to another header, etc.
Personally, I find it unbelievable that openSUSE kernel team would release a minor kernel upgrade that would screw up all users of the ATI binary driver.
I don't think there was much of a choice, since upstream decided to license the new function "GPl only". Distributions can change things in open source code, but as far as I know only BSD style licenses allow relicensing.
FYI there is a patch for the ATI driver
Anders
IMHO, this could have been handled differently. E.g., the updated kernel could have been released once an updated ATI driver was available.
As to a patch - well, it is easy to find and apply, if you're a software engineer like myself. What about the average Joe user ... So much for the strategy statement: "The target users of the openSUSE distribution are people who need to get work done and want something *stable* and usable for their every day needs."
So why are these shenanigans from upstream allowed into openSUSE? Why not disable the useless GPL only code in the Kernel as it serves no real technical purpose, it adds nothing but bloat to the Kernel. What ever happened to "free as in freedom?"
It serves no purpose other than to fix a widely exploitable root hole.
We have tests in place to ensure that the kABI doesn't change between releases, and it hasn't. The API has and that had unforseen consequences. As other people have noted, getting a quick fix out for a root exploit trumps ensuring that a proprietary driver still builds. And the module built against the last kernel still works, but still has the exploit. We chose to keep the change rather than work around it since ATI had already developed a fix (and they had to, since the upstream commit wasn't going to change to accommodate them).
-Jeff
-- Jeff Mahoney SUSE Labs
That's not what I am getting at. Of course I would expect an upstream security patch to be implemented. What I understand from Anders Johansson's post is the ATI drivers were using an API in the kernel that suddenly got marked as GPL_ONLY/Proprietary taint. And what I am getting at is why does SUSE put of with these shenanigans instead of removing the GPL_ONLY bloat out of the Kernel? I don't see how this can cause a security issue. Or now only GPL code (or malicious code marked as GPL) can cause a vulnerability? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 09/23/2010 01:59 PM, Vadym Krevs wrote:
Hi all,
just a heads up. If you use the ATI binary driver, and install the latest kernel update (2.6.34.7-0.3), then you will no longer be able to recompile the ATI driver due to missing compat_alloc_user_space() symbol in fglrx/kcl_ioctl.c.
According to http://www.gossamer-threads.com/lists/linux/kernel/1277377, the "compat_alloc_user_space()" symbol became GPL-only, got moved to another header, etc.
Personally, I find it unbelievable that openSUSE kernel team would release a minor kernel upgrade that would screw up all users of the ATI binary driver.
For the record, I was bitten by this one too. My desktop now has horrible GUI performance. I wasn't aware of the real issue, the ATI install process seemed to complete without error, but whatever driver it silently falls back to is horrible. The kernel update was driven by the dbus issue screwing things up in a different way. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hi all,
just a heads up. If you use the ATI binary driver, and install the latest kernel update (2.6.34.7-0.3), then you will no longer be able to recompile the ATI driver due to missing compat_alloc_user_space() symbol in fglrx/kcl_ioctl.c.
According to http://www.gossamer-threads.com/lists/linux/kernel/1277377, the "compat_alloc_user_space()" symbol became GPL-only, got moved to another header, etc.
Personally, I find it unbelievable that openSUSE kernel team would release a minor kernel upgrade that would screw up all users of the ATI binary driver. The ati fglrx 10.9 (8.771) driver builds fine against kernel 2.6.34.7-0.3.1. I've submitreq'ed (sr#49032) changes to X11:Drivers:Video/ati-fglrxG02 that update it to 10.9; just checkout
On 23/09/10 21:59, Vadym Krevs wrote: those sources ("osc co home:MasterPatricko:branches:X11:Drivers:Video ati-fglrxG02"), run "sh ./fetch.sh", and then "osc build -k ~/src/packages openSUSE_11.3" . I've also submitted (sr#49022) kernel build fixes discussed in this thread to the ati fglrx legacy driver (9.3) in X11:Drivers:Video/ati-fglrxG01 - so it builds on openSUSE 11.3, but I don't have the hardware to test if there are any other issues, such as an incompatible Xserver. Procedure to build/test is the same except checkout with "osc co home:MasterPatricko:branches:X11:Drivers:Video ati-fglrxG01". Hope this helps those of you stuck with ATI cards... I will update the detailed instructions I had posted earlier too (at http://masterpatricko.blogspot.com/2010/09/building-ati-fglrx-rpms-for-opens...). Regards, Tejas -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2010-09-23 at 21:59 +0100, Vadym Krevs wrote:
Hi all,
just a heads up. If you use the ATI binary driver, and install the latest kernel update (2.6.34.7-0.3), then you will no longer be able to recompile the ATI driver due to missing compat_alloc_user_space() symbol in fglrx/kcl_ioctl.c.
According to http://www.gossamer-threads.com/lists/linux/kernel/1277377, the "compat_alloc_user_space()" symbol became GPL-only, got moved to another header, etc.
Personally, I find it unbelievable that openSUSE kernel team would release a minor kernel upgrade that would screw up all users of the ATI binary driver.
This link to a hack came up in the forums: <http://ubuntuforums.org/showthread.php?t=1577815&page=2> It recreates the missing function in the kernel headers. (I'm not taking sides... I just don't have anything ATI >:-) ) - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAkyfU8UACgkQtTMYHG2NR9VN+wCfaqBxsdYoQOw+tLG17vz2MFgL 69MAn2sn93rK3wHYrDULdiAdMEFt1Evu =5RQu -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, 2010-09-26 at 16:08 +0200, Carlos E. R. wrote:
This link to a hack came up in the forums:
<http://ubuntuforums.org/showthread.php?t=1577815&page=2>
It recreates the missing function in the kernel headers.
(I'm not taking sides... I just don't have anything ATI >:-) )
I already posted a fix for the driver in this thread. Note that creating the function outside the GPL ifdef is in all likelyhood a copyright violation, you're not allowed to change the license I thought that was important to the *buntu crowd Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, Sep 26, 2010 at 11:26, Anders Johansson <ajh@nitio.de> wrote:
On Sun, 2010-09-26 at 16:08 +0200, Carlos E. R. wrote:
This link to a hack came up in the forums:
<http://ubuntuforums.org/showthread.php?t=1577815&page=2>
It recreates the missing function in the kernel headers.
(I'm not taking sides... I just don't have anything ATI >:-) )
I already posted a fix for the driver in this thread. Note that creating the function outside the GPL ifdef is in all likelyhood a copyright violation, you're not allowed to change the license
I thought that was important to the *buntu crowd
Anders
How can editing the Kernel or it's headers be a violation of its copyright? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, 2010-09-26 at 16:01 -0400, Andrew Joakimsen wrote:
How can editing the Kernel or it's headers be a violation of its copyright?
Depends on what you edit. Try to remove the GPL copyright notice and replace it with a BSD copyright, or something proprietary, and you'll have Eben Moglen on your phone before you can say Santa Cruz Operation The upstream kernel developers decided to license their new function in such a way as to be callable only from GPL licensed code. That is their prerogative as copyright holders, and you are not free to change that Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, Sep 26, 2010 at 16:07, Anders Johansson <ajh@nitio.de> wrote:
On Sun, 2010-09-26 at 16:01 -0400, Andrew Joakimsen wrote:
How can editing the Kernel or it's headers be a violation of its copyright?
Depends on what you edit. Try to remove the GPL copyright notice and replace it with a BSD copyright, or something proprietary, and you'll have Eben Moglen on your phone before you can say Santa Cruz Operation
Oh of course you need to keep the license, that is part of the GPL v2 the Kernel is licensed under. But these shenanigans are not permitted by the GPL: 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. So I don't see any reason for SUSE (or anyone else) to keep this bloat in the Kernel, especially when they are hidden in a "security patch" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, 2010-09-26 at 16:13 -0400, Andrew Joakimsen wrote:
Oh of course you need to keep the license, that is part of the GPL v2 the Kernel is licensed under. But these shenanigans are not permitted by the GPL:
6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
So I don't see any reason for SUSE (or anyone else) to keep this bloat in the Kernel, especially when they are hidden in a "security patch"
I think you need to discuss this with a lawyer. The bottom line is that it is part of an upstream licensing decision, they originate the code so they are not bound by what the GPL says you can or cannot do. They decide how their code is licensed, and suse (or any other redistributor) can't just change that. A module vendor also can't change the header simply to make his module compile, and it is doubtful if he is allowed to define the GPL macro even though his code isn't GPL, simply to allow access to the license protected code A lawyer may agree with you, I don't know. I think Eben Moglen is available for such questions, so you could try asking him Anders PS. On a semantic issue, it isn't bloat. Bloat is when unnecessary functions or features go into a binary, resulting in larger and usually slower binaries. What happened here was entirely compile-time, and has no effect at all on the size or performance of a compiled binary -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, Sep 26, 2010 at 16:20, Anders Johansson <ajh@nitio.de> wrote:
On Sun, 2010-09-26 at 16:13 -0400, Andrew Joakimsen wrote:
Oh of course you need to keep the license, that is part of the GPL v2 the Kernel is licensed under. But these shenanigans are not permitted by the GPL:
6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
So I don't see any reason for SUSE (or anyone else) to keep this bloat in the Kernel, especially when they are hidden in a "security patch"
I think you need to discuss this with a lawyer. The bottom line is that it is part of an upstream licensing decision, they originate the code so they are not bound by what the GPL says you can or cannot do. They decide how their code is licensed.
And it is GPL v2 and they are bound by that. Yes they can if they hold the full copyright distribute under another license if they so wish, but if they publish code under GPL v2 they are bound by that and anyone else can modify the code under GPLv2. They can say what they want and make you think what they want but if it is GPL there are certain rights granted, one of which is no further restrictions. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday 26 September 2010, Andrew Joakimsen wrote:
And it is GPL v2 and they are bound by that. Yes they can if they hold the full copyright distribute under another license if they so wish, but if they publish code under GPL v2 they are bound by that and anyone else can modify the code under GPLv2. They can say what they want and make you think what they want but if it is GPL there are certain rights granted, one of which is no further restrictions.
Well, you may be right. I won't pretend to know all the convoluted legal mazes surrounding licensing issues. It could well be that this was legally allowed to change. I am pretty sure it would upset the upstream devels, which is never a good idea. This alone would be reason enough to follow their wishes and not exploit the letter of the law, if that were possible Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, Sep 26, 2010 at 16:39, Anders Johansson <ajh@nitio.de> wrote:
On Sunday 26 September 2010, Andrew Joakimsen wrote:
And it is GPL v2 and they are bound by that. Yes they can if they hold the full copyright distribute under another license if they so wish, but if they publish code under GPL v2 they are bound by that and anyone else can modify the code under GPLv2. They can say what they want and make you think what they want but if it is GPL there are certain rights granted, one of which is no further restrictions.
Well, you may be right. I won't pretend to know all the convoluted legal mazes surrounding licensing issues. It could well be that this was legally allowed to change.
I am pretty sure it would upset the upstream devels, which is never a good idea. This alone would be reason enough to follow their wishes and not exploit the letter of the law, if that were possible
Linus is against it: http://lkml.org/lkml/2006/12/13/370 And I thought even further back it was decided only NEW exports would be marked GPL-only, they would not be switched. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday 26 September 2010, Andrew Joakimsen wrote:
Linus is against it: http://lkml.org/lkml/2006/12/13/370
Well, that email is four years old, so I don't think it expresses his opinion on this particular function.
And I thought even further back it was decided only NEW exports would be marked GPL-only, they would not be switched.
Well, it may be. But it did happen. Upstream did make this function GPL-only. Regardless of what you or I or anyone else thinks about it, it did in fact happen. Upstream. The writers of the code changed it. They did it. Not suse. The upstream kernel developers changed it. The licensing decision was made there, not here. By them. And, again, it changes nothing for binary drivers. They can still load and run. The ABI has not changed in any way. It only changes for people who insist on recompiling their drivers, and surely it isn't too hard for them to apply a 4 or 5 line patch? Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 09/26/2010 02:23 PM, Andrew Joakimsen wrote:
On Sun, Sep 26, 2010 at 16:39, Anders Johansson <ajh@nitio.de> wrote:
On Sunday 26 September 2010, Andrew Joakimsen wrote:
And it is GPL v2 and they are bound by that. Yes they can if they hold the full copyright distribute under another license if they so wish, but if they publish code under GPL v2 they are bound by that and anyone else can modify the code under GPLv2. They can say what they want and make you think what they want but if it is GPL there are certain rights granted, one of which is no further restrictions.
Well, you may be right. I won't pretend to know all the convoluted legal mazes surrounding licensing issues. It could well be that this was legally allowed to change.
I am pretty sure it would upset the upstream devels, which is never a good idea. This alone would be reason enough to follow their wishes and not exploit the letter of the law, if that were possible
Linus is against it: http://lkml.org/lkml/2006/12/13/370 And I thought even further back it was decided only NEW exports would be marked GPL-only, they would not be switched.
Wow. That was as brutal a smack-down as I have ever seen Linus publish. And he is spot on in his assessment. So it appears everybody did exactly what he suggested, con the Distros into inserting this stuff even tho his tree does not include it. And Opensuse played right along. -- Explain again the part about rm -rf / -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2010-09-26 at 22:20 +0200, Anders Johansson wrote:
On Sun, 2010-09-26 at 16:13 -0400, Andrew Joakimsen wrote:
So I don't see any reason for SUSE (or anyone else) to keep this bloat in the Kernel, especially when they are hidden in a "security patch"
I think you need to discuss this with a lawyer. The bottom line is that it is part of an upstream licensing decision, they originate the code so they are not bound by what the GPL says you can or cannot do. They decide how their code is licensed, and suse (or any other redistributor) can't just change that. A module vendor also can't change the header simply to make his module compile, and it is doubtful if he is allowed to define the GPL macro even though his code isn't GPL, simply to allow access to the license protected code
I don't see why SUSE/Novell has to apply this change to a kernel that was already released to us, in a stable distro. I believe the should simply correct bugs, as they always do, without upgrading the kernel, and leave further changes for factory (or KOTD). - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAkyfs1cACgkQtTMYHG2NR9UFIQCfVpC9pfbImS0qg7emCtiUyz9T XAAAn0M3pDhhTettJwxNSbq1jsP9zyM0 =jscB -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
I don't see why SUSE/Novell has to apply this change to a kernel that was already released to us, in a stable distro. I believe the should simply correct bugs, as they always do, without upgrading the kernel, and leave further changes for factory (or KOTD).
- -- Cheers, Carlos E. R. I think people are missing/forgetting something. This WAS a security
On 26/09/10 21:55, Carlos E. R. wrote: patch - all these changes are associated with CVE 2010-3081 ([1]). It's that massive 32-bit compatibility mode root exploit on 64-bit systems bug that was being discussed last week. This bug was ridiculously nasty and exploitable and a kernel security update had to be pushed out ASAP. Linus's commit: [2]. Here's an explanation of the effects of the change from the debian ML [3]: "compat-alloc-user-space() is only used for syscalls AFAIK. The rule is: you do that, you have to track the kernel. In fact, it is now GPL-only (so, for example, fglrx needs to be modified as it is forbidden from using compat-alloc-user-space()). ... Summary: compat-alloc-user-space() is now EXPORT-SYMBOL-GPL * cannot be used by fglrx and other non-GPL modules * using arch-compat-alloc-user-space() may reopen CVE-2010-3081 if the non-GPL module doesn't do access-ok by itself compat-alloc-user-space() moved from asm/compat.h to linux/compat.h * requires #include changes on out-of-tree modules that use compat-alloc-user-space() for them to build" And here's a quote from lkml [4]: "compat-alloc-user-space is still a horrible hack and shouldn't be used at all if possible." The ATI fglrx driver used buggy code - and so had to be changed. A temporary patch was available almost immediately (see Anders's post [6]), and hopefully a better one will be included in the next driver release. This was not some psuedo-religious attempt to smite evil binary drivers, this was a genuine security issue. Regardless of the merits of having GPL_ONLY kernel code at all (which is a different discussion with very important people with good arguments on both sides), this is what was necessary to fix this bug according to the kernel devs. What's the big deal? As far as I can tell, both openSUSE and the kernel devs have done a great job fixing a nasty bug very fast. If you want to discuss the merits of having EXPORT-SYMBOL-GPL at all, go to lkml, not here. Regards, Tejas [1] http://seclists.org/fulldisclosure/2010/Sep/268 [2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=... [3] http://lists.debian.org/debian-user/2010/09/msg01708.html [4] http://lkml.org/lkml/2010/9/18/18 [5] http://lists.opensuse.org/opensuse/2010-09/msg01489.html -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2010-09-27 at 11:19 +0100, Tejas Guruswamy wrote:
On 26/09/10 21:55, Carlos E. R. wrote:
I don't see why SUSE/Novell has to apply this change to a kernel that was already released to us, in a stable distro. I believe the should simply correct bugs, as they always do, without upgrading the kernel, and leave further changes for factory (or KOTD).
I think people are missing/forgetting something. This WAS a security patch - all these changes are associated with CVE 2010-3081 ([1]). It's that massive 32-bit compatibility mode root exploit on 64-bit systems bug that was being discussed last week. This bug was ridiculously nasty and exploitable and a kernel security update had to be pushed out ASAP. Linus's commit: [2].
Here's an explanation of the effects of the change from the debian ML [3]: "compat-alloc-user-space() is only used for syscalls AFAIK. The rule is: you do that, you have to track the kernel. In fact, it is now GPL-only (so, for example, fglrx needs to be modified as it is forbidden from using compat-alloc-user-space()). ... Summary: compat-alloc-user-space() is now EXPORT-SYMBOL-GPL * cannot be used by fglrx and other non-GPL modules * using arch-compat-alloc-user-space() may reopen CVE-2010-3081 if the non-GPL module doesn't do access-ok by itself compat-alloc-user-space() moved from asm/compat.h to linux/compat.h * requires #include changes on out-of-tree modules that use compat-alloc-user-space() for them to build"
And here's a quote from lkml [4]: "compat-alloc-user-space is still a horrible hack and shouldn't be used at all if possible."
The ATI fglrx driver used buggy code - and so had to be changed. A temporary patch was available almost immediately (see Anders's post [6]), and hopefully a better one will be included in the next driver release. This was not some psuedo-religious attempt to smite evil binary drivers, this was a genuine security issue.
Regardless of the merits of having GPL_ONLY kernel code at all (which is a different discussion with very important people with good arguments on both sides), this is what was necessary to fix this bug according to the kernel devs.
Thanks for the clear explanation, it was needed and appreciated. Nobody had said here yet (or we missed it) that the security problem was precisely that function that the ati driver uses. The remaining question is to document what users of ATI cards (all types) have to do to get a working driver. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAkygdQsACgkQtTMYHG2NR9X1JwCeI8BxDEkw2zfe/1CpBNX+W7hF c90AoIuprC+tFXKzleXBd1bctj5Q2r1G =DzeX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, Sep 27, 2010 at 06:19, Tejas Guruswamy <masterpatricko@gmail.com> wrote:
I don't see why SUSE/Novell has to apply this change to a kernel that was already released to us, in a stable distro. I believe the should simply correct bugs, as they always do, without upgrading the kernel, and leave further changes for factory (or KOTD).
- -- Cheers, Carlos E. R. I think people are missing/forgetting something. This WAS a security
On 26/09/10 21:55, Carlos E. R. wrote: patch - all these changes are associated with CVE 2010-3081 ([1]). It's that massive 32-bit compatibility mode root exploit on 64-bit systems bug that was being discussed last week. This bug was ridiculously nasty and exploitable and a kernel security update had to be pushed out ASAP. Linus's commit: [2].
Here's an explanation of the effects of the change from the debian ML [3]: "compat-alloc-user-space() is only used for syscalls AFAIK. The rule is: you do that, you have to track the kernel. In fact, it is now GPL-only (so, for example, fglrx needs to be modified as it is forbidden from using compat-alloc-user-space()). ... Summary: compat-alloc-user-space() is now EXPORT-SYMBOL-GPL * cannot be used by fglrx and other non-GPL modules * using arch-compat-alloc-user-space() may reopen CVE-2010-3081 if the non-GPL module doesn't do access-ok by itself compat-alloc-user-space() moved from asm/compat.h to linux/compat.h * requires #include changes on out-of-tree modules that use compat-alloc-user-space() for them to build"
And here's a quote from lkml [4]: "compat-alloc-user-space is still a horrible hack and shouldn't be used at all if possible."
The ATI fglrx driver used buggy code - and so had to be changed. A temporary patch was available almost immediately (see Anders's post [6]), and hopefully a better one will be included in the next driver release. This was not some psuedo-religious attempt to smite evil binary drivers, this was a genuine security issue.
Regardless of the merits of having GPL_ONLY kernel code at all (which is a different discussion with very important people with good arguments on both sides), this is what was necessary to fix this bug according to the kernel devs.
What's the big deal? As far as I can tell, both openSUSE and the kernel devs have done a great job fixing a nasty bug very fast. If you want to discuss the merits of having EXPORT-SYMBOL-GPL at all, go to lkml, not here.
Regards, Tejas
[1] http://seclists.org/fulldisclosure/2010/Sep/268 [2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=... [3] http://lists.debian.org/debian-user/2010/09/msg01708.html [4] http://lkml.org/lkml/2010/9/18/18 [5] http://lists.opensuse.org/opensuse/2010-09/msg01489.html -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
So now malicious code marks itself as GPL and nothing is fixed, because it has access to the same API as before. -- Med Vennlig Hilsen, A. Helge Joakimsen -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2010-09-26 at 17:26 +0200, Anders Johansson wrote:
On Sun, 2010-09-26 at 16:08 +0200, Carlos E. R. wrote:
This link to a hack came up in the forums:
<http://ubuntuforums.org/showthread.php?t=1577815&page=2>
It recreates the missing function in the kernel headers.
(I'm not taking sides... I just don't have anything ATI >:-) )
I already posted a fix for the driver in this thread. Note that creating the function outside the GPL ifdef is in all likelyhood a copyright violation, you're not allowed to change the license
- From a post in our forum: ]> The patch of the fglrx driver code does not work for me since the code ]> is overwritten from the rpm package every time the package is built. If ]> there were a way to patch the code in the RPM package...? I understand the rpm installation builds something, that would need the patch inplace. So it doesn't work. As I don't have an ATI card, I don't know what to tell them - they have to patch the kernel instead. Can somebody post complete instructions? Here, in our forum, or in the wiki, please? - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAkyf6skACgkQtTMYHG2NR9U64QCfQUhe1yI0DgrWaNwozrehXPcv 1OwAoIbSY0qQkmP++IqD7S5ygrNR4H+6 =X8Bn -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Monday 27 September 2010, Carlos E. R. wrote:
On Sunday, 2010-09-26 at 17:26 +0200, Anders Johansson wrote:
On Sun, 2010-09-26 at 16:08 +0200, Carlos E. R. wrote:
This link to a hack came up in the forums:
<http://ubuntuforums.org/showthread.php?t=1577815&page=2>
It recreates the missing function in the kernel headers.
(I'm not taking sides... I just don't have anything ATI >:-) )
I already posted a fix for the driver in this thread. Note that creating the function outside the GPL ifdef is in all likelyhood a copyright violation, you're not allowed to change the license
From a post in our forum:
]> The patch of the fglrx driver code does not work for me since the code ]> is overwritten from the rpm package every time the package is built. If ]> there were a way to patch the code in the RPM package...?
Why are they rebuilding the package *at all*? It is not needed! The binary driver they already have will work without being rebuilt!
Can somebody post complete instructions? Here, in our forum, or in the wiki, please?
cd /usr/src/kernel-modules/fglrx apply the above-mentioned patch make make install Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, 2010-09-26 at 16:08 +0200, Carlos E. R. wrote:
This link to a hack came up in the forums:
<http://ubuntuforums.org/showthread.php?t=1577815&page=2>
It recreates the missing function in the kernel headers.
By the way, it will most likely break all GPL modules using it, since they will now see two definitions. Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2010-09-26 at 17:35 +0200, Anders Johansson wrote:
On Sun, 2010-09-26 at 16:08 +0200, Carlos E. R. wrote:
This link to a hack came up in the forums:
<http://ubuntuforums.org/showthread.php?t=1577815&page=2>
It recreates the missing function in the kernel headers.
By the way, it will most likely break all GPL modules using it, since they will now see two definitions.
Whatever :-) I do not know, I posted it here for others to comment. It is obvious that people need a working solution, so they hack away, regardless of licenses. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAkyfa14ACgkQtTMYHG2NR9Uk+gCfc0ooX3T88LeGfx5DLWrFwHr5 DiwAnAxxGnaZ9WRJ2m9c1pYzBHpIdRbg =ftC6 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, 2010-09-26 at 17:48 +0200, Carlos E. R. wrote:
Whatever :-)
I do not know, I posted it here for others to comment. It is obvious that people need a working solution, so they hack away, regardless of licenses.
Yeah, well, there already is one, which is also legal. But just continuing to use the driver that was built for the previous kernel without rebuilding anything will also work Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday, 2010-09-26 at 17:35 +0200, Anders Johansson wrote:
On Sun, 2010-09-26 at 16:08 +0200, Carlos E. R. wrote:
This link to a hack came up in the forums:
<http://ubuntuforums.org/showthread.php?t=1577815&page=2>
It recreates the missing function in the kernel headers.
By the way, it will most likely break all GPL modules using it, since they will now see two definitions. Whatever :-)
I do not know, I posted it here for others to comment. It is obvious that people need a working solution, so they hack away, regardless of licenses.
- -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) As far as I can tell, this patch reopens the security hole as well --
On 26/09/10 16:48, Carlos E. R. wrote: please advise anyone who has seen it that it should not be used under any circumstances. Regards, Tejas -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2010-09-27 at 12:14 +0100, Tejas Guruswamy wrote:
As far as I can tell, this patch reopens the security hole as well -- please advise anyone who has seen it that it should not be used under any circumstances.
- From your previous explanation, I understand that as well. But people needing a solution will use it, regardless. I can not say what is the proper procedure. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAkyggYoACgkQtTMYHG2NR9Vk6QCfRwB5rvQxMkRA0fH6I90zdaKo XzIAnRG0iAmEdS9XZei/caP/JDuGNG20 =vk5h -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Monday 27 September 2010 13:35:31 Carlos E. R. wrote:
I can not say what is the proper procedure.
It's the second time you say that. Out of curiosity, what was wrong with my step-by-step description? Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2010-09-27 at 13:56 +0200, Anders Johansson wrote:
On Monday 27 September 2010 13:35:31 Carlos E. R. wrote:
I can not say what is the proper procedure.
It's the second time you say that. Out of curiosity, what was wrong with my step-by-step description?
Strictly what I said: that _I_ can not say, because I do not know, I'm not affected. I'm commenting on what others say, and passing info from the forum to the list, and back, for others. I suggest that you people that know the issue drop down by the fora and talk to people there, having problems ;-) I simply copied your instructions: ··· cd /usr/src/kernel-modules/fglrx apply the above-mentioned patch make make install ··· to the forum, and I'm waiting for comments. I assume that's the "step-by-step description" you mean? Also, I have no idea why they can't simply use the rpm with drivers, readily made, I assume. I asked why, no reply yet. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAkygjS0ACgkQtTMYHG2NR9Ul6QCeNe1634gmFshQPwFIPjDOg4US ebsAoIIZP12XdZqDygeNNR4rbT+xvvQj =6sDB -----END PGP SIGNATURE-----
On 27/09/10 12:35, Carlos E. R. wrote:
> On Monday, 2010-09-27 at 12:14 +0100, Tejas Guruswamy wrote:
>> As far as I can tell, this patch reopens the security hole as well --
>> please advise anyone who has seen it that it should not be used under
>> any circumstances.
> - From your previous explanation, I understand that as well. But
> people needing a solution will use it, regardless.
>
> I can not say what is the proper procedure.
>
> - -- Cheers,
> Carlos E. R.
> (from 11.2 x86_64 "Emerald" at Telcontar)
Patch fglrx, not the kernel.
If you are using ati-driver shell script installer, do as Anders wrote:
install until the compilation error
save the patch [1] somewhere as CVE-2010-3081.diff
> cd /usr/src/kernel-modules/fglrx
> patch -p0 < ${patch_location}/CVE-2010-3081.diff
> make
> make install
- or -
IMO, cleaner, rebuild from the obs project X11:Drivers:Video as I've
discussed before
( uninstall any existing ati drivers )
> sudo zypper in osc
> mkdir ~/src; cd ~/src
> osc co X11:Drivers:Video ati-fglrxG02
> cd X11\:Drivers\:Video/ati-fglrxG02
> mkdir ~/src/packages
> osc build -k ~/src/packages -j 4 openSUSE_11.3 x86_64
ati-fglrxG02.spec #change arch/distro version as necessary
> osc build -k ~/src/packages -j 4 openSUSE_11.3 x86_64
x11-video-fglrxG02.spec #change arch/distro version as necessary
> cd ~/src/packages
> sudo zypper in -f ati-fglrxG02-kmp-desktop-8.771_*.x86_64.rpm \
x11-video-fglrxG02-8.771-*.x86_64.rpm
(see
http://masterpatricko.blogspot.com/2010/09/building-ati-fglrx-rpms-for-opensuse.html)
Regards
Tejas
[1] CVE-2010-3081.diff
--- kcl_ioctl.c
+++ kcl_ioctl.c
@@ -193,7 +193,13 @@
*/
void* ATI_API_CALL KCL_IOCTL_AllocUserSpace32(long size)
{
- return compat_alloc_user_space(size);
+ void __user *ret = arch_compat_alloc_user_space(size);
+
+ /* prevent stack overflow */
+ if (!access_ok(VERIFY_WRITE, ret, size))
+ return NULL;
+
+ return (void *)ret;
}
#endif // __x86_64__
--
To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org
For additional commands, e-mail: opensuse+help@opensuse.org
participants (16)
-
Anders Johansson -
Anders Johansson -
Andrew Joakimsen -
Carlos E. R. -
Carlos E. R. -
David C. Rankin -
Graham Anderson -
Jeff Mahoney -
John Andersen -
jsa
-
Lew Wolfgang -
Marcus Meissner -
Michael Powell -
Patrick Shanahan -
Tejas Guruswamy -
Vadym Krevs