I am submitting this report to this list for documentation, perspectives and, hopefully, helpful assistance towards resolving this issue. Sorry in advance for the length of this post.
First reported to the Unofficial Wiki + Bugzilla of the ATI fglrx binary, then to AMD/ATI technical support was the following issue:
I have the following configuration: * Lenovo Thinkpad T60p * ATI Mobility FireGL V5250 graphics card * version 8.52.3 of the fglrx module * Fedora 8 running version 2.6.25.14-69.fc8 of the GNU/Linux kernel
*NOTE: I have upgraded the kernel and driver from the first indications of the problem; hence, older versions are in the bug report below. However, the same bug persists according to both symptoms and to the security log.
At intermittent start-ups of the X server using the fglrx driver the X server does not display due to a security compatibility problem between the fglrx driver and the secure SELinux module of the GNU/linux kernel. The following is the report from the system log outlining the problem:
SELinux: out of range capability -157851600 ------------[ cut here ]------------ kernel BUG at security/selinux/hooks.c:1332! invalid opcode: 0000 [#1] SMP Modules linked in: ipv6 snd_hda_intel snd_seq_dummy snd_seq_oss arc4 snd_seq_midi_event snd_seq ecb snd_seq_device crypto_blkcipher snd_pcm_oss snd_mixer_oss snd_pcm i2c_i801 iwl3945 iTCO_wdt battery iTCO_vendor_support snd_timer i2c_core ac mac80211 video thinkpad_acpi bay snd_page_alloc irda output snd_hwdep e1000e button snd cfg80211 crc_ccitt fglrx(P)(U) pcspkr hwmon soundcore sr_mod cdrom sg usb_storage ata_piix dm_snapshot dm_zero dm_mirror dm_mod ahci libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: scsi_wait_scan]
Pid: 1488, comm: Xorg Tainted: P (2.6.25.6-27.fc8 #1) EIP: 0060:[<c04cd328>] EFLAGS: 00213246 CPU: 1 EIP is at task_has_capability+0x46/0x79 EAX: 00000030 EBX: f6976030 ECX: 00203046 EDX: 00203046 ESI: f685f200 EDI: f6959eb0 EBP: f6959ebc ESP: f6959e6c DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process Xorg (pid: 1488, ti=f6959000 task=f6f98000 task.ti=f6959000) Stack: c06d780d f6976030 f6f98000 00000003 f6f98000 f6976030 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 f6976030 f6f98000 f69ca000 f6959ecc c04cd37a f6f98000 f9678400 Call Trace: [<c04cd37a>] ? selinux_capable+0x1f/0x23 [<c04c973d>] ? security_capable+0xc/0xe [<c042ca37>] ? __capable+0xb/0x1f [<f954e670>] ? firegl_version+0x0/0x1b0 [fglrx] [<c042ca5b>] ? capable+0x10/0x12 [<f954e537>] ? firegl_ioctl+0xe7/0x220 [fglrx] [<c046e370>] ? handle_mm_fault+0x64f/0x6ef [<f9543c80>] ? ip_firegl_ioctl+0xe/0x10 [fglrx] [<c048ad76>] ? vfs_ioctl+0x4e/0x67 [<c048aff1>] ? do_vfs_ioctl+0x262/0x279 [<c04d0226>] ? selinux_file_ioctl+0xa8/0xab [<c048b048>] ? sys_ioctl+0x40/0x5c [<c0405b7e>] ? syscall_call+0x7/0xb ======================= Code: 05 00 00 89 d0 f3 ab 8b 4d b8 89 d8 b2 04 c1 f8 05 c6 45 bc 03 89 5d c4 89 4d c0 74 19 48 74 11 53 68 0d 78 6d c0 e8 6d 9e f5 ff <0f> 0b 58 5a eb fe ba 45 00 00 00 8b 46 08 83 e3 1f 0f b7 f2 8d EIP: [<c04cd328>] task_has_capability+0x46/0x79 SS:ESP 0068:f6959e6c ---[ end trace 93d33da5bd859df0 ]--- [fglrx:firegl_release] *ERROR* device busy: 1 0 [fglrx] release failed with code -EBUSY
-------------------- End of report -------------------
AMD/ATI's response is as follows:
I regret there is no support for Linux at this time.
Please see the following
737-28027: LINUX support for ATI Video cards
LINUX support for ATI Video cards:
Although we have drivers for Linux posted on the ATI website, we do not provide technical support for driver or multimedia issues in Linux directly.
The Linux drivers available (For laptops, RADEON and All in wonder Products) from AMD are provided are "as is".
If you are looking for drivers then go to: http://ati.amd.com/support/driver.html
For information regarding the ATI Proprietary Linux Driver visit: http://www.ati.com/products/catalyst/linux.html
Our web site offers several links to Linux support websites that may help you.
The link below has information that might be helpful to your case.
http://wiki.cchtml.com/index.php/Main_Page%5C
There are also very good articles from third parties:
1. http://www.rage3d.com/content/articles/atilinuxhowto/Linux_ATI.html#SECTION0... 2. http://www.linux.org/help/index.html 3. http://www.linuxdoc.org/ 4. http://www.xfree86.org/
To report issues with Linux drivers you can submit an online ticket using the “Linux Driver Feedback” category, and your report will be received and reviewed/tested by our driver team. Please note that your report will only be responded to if we require additional information. We do not respond to all support inquires.
For the Linux Driver Feedback submission page, visit.
http://support.ati.com/ics/survey/survey.asp?deptID=894&surveyID=508&...
---------------- End of response -----------------
I could disable SELinux and I would not have this problem; however, I was hoping that there was a much secure or safer work-around to this problem.
Peace, Frank
On Wed, 24 Sep 2008, Francis K Shim wrote:
I could disable SELinux and I would not have this problem; however, I was hoping that there was a much secure or safer work-around to this problem.
The video driver is inherently dangerous, so the safe approach is not to use it.
- James
On Thu, 2008-09-25 at 14:15 +1000, James Morris wrote:
On Wed, 24 Sep 2008, Francis K Shim wrote:
I could disable SELinux and I would not have this problem; however, I was hoping that there was a much secure or safer work-around to this problem.
The video driver is inherently dangerous, so the safe approach is not to use it.
James isn't exactly being helpful, but the reason is because as you guessed the problem lies squarely and obviously with AMD/ATI and there isn't much we can do to help with closed source proprietary software. AMD/ATI is obviously doing it wrong and when it comes to security doing it wrong is never a good idea. Sadly we don't have their source so I can't show you the line of code (or do anything to fix it), but your backtrace should make it pretty obvious if anyone inside ATI decides to care.
Stephen James, what do the two of you think about something like this? Maybe a WARN_ONCE() ?
security/selinux/hooks.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 03fc6a8..14f1242 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -1385,7 +1385,8 @@ static int task_has_capability(struct task_struct *tsk, default: printk(KERN_ERR "SELinux: out of range capability %d\n", cap); - BUG(); + WARN(); + return -EPERM; } return avc_has_perm(tsec->sid, tsec->sid, sclass, av, &ad); }
On Thu, 2008-09-25 at 09:13 -0400, Eric Paris wrote:
On Thu, 2008-09-25 at 14:15 +1000, James Morris wrote:
On Wed, 24 Sep 2008, Francis K Shim wrote:
I could disable SELinux and I would not have this problem; however, I was hoping that there was a much secure or safer work-around to this problem.
The video driver is inherently dangerous, so the safe approach is not to use it.
James isn't exactly being helpful, but the reason is because as you guessed the problem lies squarely and obviously with AMD/ATI and there isn't much we can do to help with closed source proprietary software. AMD/ATI is obviously doing it wrong and when it comes to security doing it wrong is never a good idea. Sadly we don't have their source so I can't show you the line of code (or do anything to fix it), but your backtrace should make it pretty obvious if anyone inside ATI decides to care.
Stephen James, what do the two of you think about something like this? Maybe a WARN_ONCE() ?
Maybe instead of returning -EPERM unconditionally, returning based on the unknown_perms setting? Of course what to do if its set to reject would be a question (my suggestion would be deny on that too).
security/selinux/hooks.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 03fc6a8..14f1242 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -1385,7 +1385,8 @@ static int task_has_capability(struct task_struct *tsk, default: printk(KERN_ERR "SELinux: out of range capability %d\n", cap);
BUG();
WARN();
} return avc_has_perm(tsec->sid, tsec->sid, sclass, av, &ad);return -EPERM;
}
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Thu, 25 Sep 2008, Eric Paris wrote:
Stephen James, what do the two of you think about something like this? Maybe a WARN_ONCE() ?
There are several issues here:
- Does this actually solve the problem for the user? What happens when the driver gets an -EPERM there?
- Should we be littering the kernel code with workarounds for bugs in proprietary drivers?
- Should we be encouraging vendors to not support Linux users, especially when other vendors are offering support (who we would then also be discouraging).
- Francis asked for a much-secure or safer workaround to the issue. Given that the driver is messing with kernel security, is also broken in its use of a security API, and not maintained, I'm certainly not going to recommend its continued use in this context.
- James
On Fri, 26 Sep 2008 00:31:09 +1000, James Morris said:
- Francis asked for a much-secure or safer workaround to the issue.
Given that the driver is messing with kernel security, is also broken in its use of a security API, and not maintained, I'm certainly not going to recommend its continued use in this context.
Given the fact it's a kernel BUG, I wonder if the *real* issue isn't that the driver doesn't support SELinux, but that it doesn't understand the expanded more-than-32-bits capabilities in recent kernels, causing something to overlay something it shouldn't have...
On Thu, 2008-09-25 at 23:38 -0400, Valdis.Kletnieks@vt.edu wrote:
On Fri, 26 Sep 2008 00:31:09 +1000, James Morris said:
- Francis asked for a much-secure or safer workaround to the issue.
Given that the driver is messing with kernel security, is also broken in its use of a security API, and not maintained, I'm certainly not going to recommend its continued use in this context.
From the perspective of security and safety, I agree with James in
simply *not* using the fglrx driver, in favor of a VESA or compatible open-source device driver; however, that being said, it will essentially cripple the usage of the full range of the video card's capabilities. It is acceptable if I were to only be limited to simple text editing and low intensity graphics. However, it does mean that any photo-realistic and intense graphics manipulation will suffer, which I can live with for a little while, but not forever.
Given the fact it's a kernel BUG, I wonder if the *real* issue isn't that the driver doesn't support SELinux, but that it doesn't understand the expanded more-than-32-bits capabilities in recent kernels, causing something to overlay something it shouldn't have...
If this is the case, then I would be happy to tell AMD/ATI about this interface bug; however, I think that SELinux itself, Linux and the Open-source community should use incidences like this as further proof-of-application (versus proof-of-concept). At least, in this respect, there should be an opportunity for strengthening liason between *us* and the AMD/ATI team.
Peace, Frank
On Thu, 2008-09-25 at 09:13 -0400, Eric Paris wrote:
On Thu, 2008-09-25 at 14:15 +1000, James Morris wrote:
On Wed, 24 Sep 2008, Francis K Shim wrote:
I could disable SELinux and I would not have this problem; however, I was hoping that there was a much secure or safer work-around to this problem.
The video driver is inherently dangerous, so the safe approach is not to use it.
James isn't exactly being helpful, but the reason is because as you guessed the problem lies squarely and obviously with AMD/ATI and there isn't much we can do to help with closed source proprietary software. AMD/ATI is obviously doing it wrong and when it comes to security doing it wrong is never a good idea. Sadly we don't have their source so I can't show you the line of code (or do anything to fix it), but your backtrace should make it pretty obvious if anyone inside ATI decides to care.
Stephen James, what do the two of you think about something like this? Maybe a WARN_ONCE() ?
security/selinux/hooks.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 03fc6a8..14f1242 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -1385,7 +1385,8 @@ static int task_has_capability(struct task_struct *tsk, default: printk(KERN_ERR "SELinux: out of range capability %d\n", cap);
BUG();
WARN();
} return avc_has_perm(tsec->sid, tsec->sid, sclass, av, &ad);return -EPERM;
}
I'm not opposed to changing it to an error return, although I'm not clear that will help.
Does anyone know what the driver is actually trying to do here? The message said: SELinux: out of range capability -157851600 and -157851600 == 0xf6976030 Obviously that isn't what they meant to pass to capable().
On Mon, 2008-09-29 at 09:13 -0400, Stephen Smalley wrote:
On Thu, 2008-09-25 at 09:13 -0400, Eric Paris wrote:
On Thu, 2008-09-25 at 14:15 +1000, James Morris wrote:
On Wed, 24 Sep 2008, Francis K Shim wrote:
I could disable SELinux and I would not have this problem; however, I was hoping that there was a much secure or safer work-around to this problem.
The video driver is inherently dangerous, so the safe approach is not to use it.
James isn't exactly being helpful, but the reason is because as you guessed the problem lies squarely and obviously with AMD/ATI and there isn't much we can do to help with closed source proprietary software. AMD/ATI is obviously doing it wrong and when it comes to security doing it wrong is never a good idea. Sadly we don't have their source so I can't show you the line of code (or do anything to fix it), but your backtrace should make it pretty obvious if anyone inside ATI decides to care.
Stephen James, what do the two of you think about something like this? Maybe a WARN_ONCE() ?
security/selinux/hooks.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 03fc6a8..14f1242 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -1385,7 +1385,8 @@ static int task_has_capability(struct task_struct *tsk, default: printk(KERN_ERR "SELinux: out of range capability %d\n", cap);
BUG();
WARN();
} return avc_has_perm(tsec->sid, tsec->sid, sclass, av, &ad);return -EPERM;
}
I'm not opposed to changing it to an error return, although I'm not clear that will help.
Does anyone know what the driver is actually trying to do here? The message said: SELinux: out of range capability -157851600 and -157851600 == 0xf6976030 Obviously that isn't what they meant to pass to capable().
I don't think any of us have any idea what the driver was trying to do here, but clearly they are doing it wrong. Maybe you can turn on your NSA brain reading satellite and peer into the brain of an ATI programmer....
I'm actually quite shocked it didn't blow up in cap_raised
#define cap_raised(c, flag) ((c).cap[CAP_TO_INDEX(flag)] & CAP_TO_MASK(flag))
its just got to be darn lucky that c.cap[huge index] actually hit a legal spot of memory and didn't bug on a pagefault right there. (I'm pretty sure 64 bit capabilities were in 2.6.25 right?) Before 64 bit caps I don't think we had the array index and only had the mask, so something huge wouldn't explode in the cap code...
We can turn this into a WARN_ONCE() but people with this driver would still be taking a walk on the wild side since there is no bounds checking what-so-ever in the cap code....
I feel your pain, and we can make the kernel stop BUGing in SELinux code, but after looking at the cap code that it already ran your just as likely to BUG even without SELinux (and not nearly as cleanly...)
I'm sorry to say I think its probably best for us to leave the BUG so at least the kernel will explode predictably rather than randomly and in a harder to track down way...
I wonder if I should propose adding a cap_valid() check to cap_capable() upstream...
-Eric
On Mon, 2008-09-29 at 09:31 -0400, Eric Paris wrote:
I wonder if I should propose adding a cap_valid() check to cap_capable() upstream...
Couple minutes on kernelopps.org showed that almost 3000 others had this same problem. So anyway, the problem is absolutely in the firegl code but I did propose something upstream to try to hopefully keep people's computers alive. We'll see what the comments are....
http://marc.info/?l=linux-kernel&m=122278342811993&w=2
-Eric
Thanks for the further information.
Eric, I hope you do not mind, but I forwarded this information to the AMD/ATI technical support using their ticket system.
I am hoping that somehow a light-bulb will actually go off among the "customer technical support" crew to actually forward this and past information to their actual coders/programmers.
Peace, Frank
On Tue, 2008-09-30 at 10:08 -0400, Eric Paris wrote:
2
selinux@lists.fedoraproject.org