Bug#336220: xdm: bogus /dev/mem access lead to trouble on arm platforms
On Sun, Aug 19, 2007 at 02:31:49PM +0200, Brice Goglin wrote: On Fri, Oct 28, 2005 at 07:47:14PM +0200, Lennert Buytenhek wrote: On arm platforms where physical RAM doesn't start at physical address zero, opening /dev/mem and reading from it causes a kernel oops. This is arguably a kernel bug, but it's still not a very good idea to just start randomly poking around in /dev/mem in search of entropy, which is what xdm does if it can't get entropy elsewhere. (When the kernel is fixed, blindly reading from /dev/mem will simply just fail with EFAULT instead of oopsing. If that will cause xdm to fail, it should really just fail right away if /dev/random doesn't work.) xdm seems to try /dev/urandom first nowadays (before /dev/random and then /dev/mem). I don't whether arm systems have a /dev/urandom, but it seems more likely than having a /dev/random. I don't know which version of xdm you were running when you reported this problem (Xorg 6.8.2 was the latest release on 2005/10/28). But it was at the same time that the urandom support has been added upstream (in Xorg 6.9.99.902 on 2005/10/29). So please test with a more recent xdm and report back whether it helps. Ping? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336220: xdm: bogus /dev/mem access lead to trouble on arm platforms
On Mon, Sep 17, 2007 at 08:55:49AM +0200, Brice Goglin wrote: On arm platforms where physical RAM doesn't start at physical address zero, opening /dev/mem and reading from it causes a kernel oops. This is arguably a kernel bug, but it's still not a very good idea to just start randomly poking around in /dev/mem in search of entropy, which is what xdm does if it can't get entropy elsewhere. (When the kernel is fixed, blindly reading from /dev/mem will simply just fail with EFAULT instead of oopsing. If that will cause xdm to fail, it should really just fail right away if /dev/random doesn't work.) xdm seems to try /dev/urandom first nowadays (before /dev/random and then /dev/mem). I don't whether arm systems have a /dev/urandom, but it seems more likely than having a /dev/random. I don't know which version of xdm you were running when you reported this problem (Xorg 6.8.2 was the latest release on 2005/10/28). But it was at the same time that the urandom support has been added upstream (in Xorg 6.9.99.902 on 2005/10/29). So please test with a more recent xdm and report back whether it helps. Ping? I'm not sure what to reply to this. The problem is not that xdm doesn't check /dev/urandom first, the problem is that it reads from /dev/mem _at all_. It is possible that checking /dev/urandom first masks the problem in most configurations, but it doesn't solve it (if you don't have /dev/random and /dev/urandom in your filesystem for whatever reason, you still oops.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336220: xdm: bogus /dev/mem access lead to trouble on arm platforms
Lennert Buytenhek wrote: The problem is not that xdm doesn't check /dev/urandom first, the problem is that it reads from /dev/mem _at all_. It is possible that checking /dev/urandom first masks the problem in most configurations, but it doesn't solve it (if you don't have /dev/random and /dev/urandom in your filesystem for whatever reason, you still oops.) Right, but still, having a workaround when /dev/urandom exists is much better than having xdm broken on all arm. So, do you know if /dev/urandom is more often (always?) available on arm than /dev/random? What about the machine where you had the original bug? Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336220: xdm: bogus /dev/mem access lead to trouble on arm platforms
On Fri, Oct 28, 2005 at 07:47:14PM +0200, Lennert Buytenhek wrote: On arm platforms where physical RAM doesn't start at physical address zero, opening /dev/mem and reading from it causes a kernel oops. This is arguably a kernel bug, but it's still not a very good idea to just start randomly poking around in /dev/mem in search of entropy, which is what xdm does if it can't get entropy elsewhere. (When the kernel is fixed, blindly reading from /dev/mem will simply just fail with EFAULT instead of oopsing. If that will cause xdm to fail, it should really just fail right away if /dev/random doesn't work.) xdm seems to try /dev/urandom first nowadays (before /dev/random and then /dev/mem). I don't whether arm systems have a /dev/urandom, but it seems more likely than having a /dev/random. I don't know which version of xdm you were running when you reported this problem (Xorg 6.8.2 was the latest release on 2005/10/28). But it was at the same time that the urandom support has been added upstream (in Xorg 6.9.99.902 on 2005/10/29). So please test with a more recent xdm and report back whether it helps. Thanks Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336220: xdm: bogus /dev/mem access lead to trouble on arm platforms
Package: xdm Severity: important On arm platforms where physical RAM doesn't start at physical address zero, opening /dev/mem and reading from it causes a kernel oops. This is arguably a kernel bug, but it's still not a very good idea to just start randomly poking around in /dev/mem in search of entropy, which is what xdm does if it can't get entropy elsewhere. (When the kernel is fixed, blindly reading from /dev/mem will simply just fail with EFAULT instead of oopsing. If that will cause xdm to fail, it should really just fail right away if /dev/random doesn't work.) -- System Information: Debian Release: testing/unstable APT prefers stable APT policy: (500, 'stable') Architecture: armeb (armv4b) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
