Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Oct 21, 2002 at 08:12:45PM +0200, Guido Guenther wrote: > xdm as of 4.2.1-3 still let's the kernel on mips oops. I assume it's > still the issue of reading blindly from /dev/mem. Do you have any > further plans regarding this issue? Yes. Forgot. Adding it to TODO list. -- G. Branden Robinson|People are equally horrified at Debian GNU/Linux |hearing the Christian religion [EMAIL PROTECTED] |doubted, and at seeing it http://people.debian.org/~branden/ |practiced. -- Samuel Butler pgp9zW0r9bcF4.pgp Description: PGP signature
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Oct 21, 2002 at 08:12:45PM +0200, Guido Guenther wrote: > xdm as of 4.2.1-3 still let's the kernel on mips oops. I assume it's > still the issue of reading blindly from /dev/mem. Do you have any > further plans regarding this issue? Yes. Forgot. Adding it to TODO list. -- G. Branden Robinson|People are equally horrified at Debian GNU/Linux |hearing the Christian religion [EMAIL PROTECTED] |doubted, and at seeing it http://people.debian.org/~branden/ |practiced. -- Samuel Butler msg04249/pgp0.pgp Description: PGP signature
Re: a small C program to test xdm's /dev/mem reading on your architecture
Hi Branden, On Mon, Aug 26, 2002 at 01:20:33AM -0500, Branden Robinson wrote: > The X Strike Force is trying to determine for which architectures it's a > bad idea to read several megabytes of data sequentially from /dev/mem, > because this is exactly what XDM currently does when generating an > XDM-AUTHORIZATION-1 cookie. xdm as of 4.2.1-3 still let's the kernel on mips oops. I assume it's still the issue of reading blindly from /dev/mem. Do you have any further plans regarding this issue? Regards, -- Guido pgpfocmA5GbSm.pgp Description: PGP signature
Re: a small C program to test xdm's /dev/mem reading on your architecture
Hi Branden, On Mon, Aug 26, 2002 at 01:20:33AM -0500, Branden Robinson wrote: > The X Strike Force is trying to determine for which architectures it's a > bad idea to read several megabytes of data sequentially from /dev/mem, > because this is exactly what XDM currently does when generating an > XDM-AUTHORIZATION-1 cookie. xdm as of 4.2.1-3 still let's the kernel on mips oops. I assume it's still the issue of reading blindly from /dev/mem. Do you have any further plans regarding this issue? Regards, -- Guido msg04244/pgp0.pgp Description: PGP signature
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Fri, Aug 30, 2002 at 01:58:43PM +0100, Jonathan Amery wrote: > In article <[EMAIL PROTECTED]> Branden writes: > >> I can't believe he actually intends to keep it like this.. > >I'm going to #define DEV_RANDOM /dev/random for Linux systems. > > And Debian Hurd? Or does the Hurd not have /dev/random or /dev/urandom? > > I suspect that /dev/urandom may be the better choice, however. On GNU/Hurd targets, /dev/urandom should be used. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Fri, Aug 30, 2002 at 01:50:59PM +0100, Jonathan Amery wrote: > Actually, the standard configuration is that /dev/mem is read. The > code to read from /dev/(u)random isn't activated in any situation in > the standard upstream X distribution, and given that it contains an > error that stops it from compiling[1] I suspect that it has only ever > rarely been used. I see no footnote. :) -- G. Branden Robinson| To stay young requires unceasing Debian GNU/Linux | cultivation of the ability to [EMAIL PROTECTED] | unlearn old falsehoods. http://people.debian.org/~branden/ | -- Robert Heinlein pgpDCeMyGpZu8.pgp Description: PGP signature
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Fri, 30 Aug 2002, Jonathan Amery wrote: >Date: Fri, 30 Aug 2002 13:58:43 +0100 >From: Jonathan Amery <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED], debian-x@lists.debian.org >Subject: Re: a small C program to test xdm's /dev/mem reading on your >architecture > >In article <[EMAIL PROTECTED]> Branden writes: >>> I can't believe he actually intends to keep it like this.. >>I'm going to #define DEV_RANDOM /dev/random for Linux systems. > > And Debian Hurd? Or does the Hurd not have /dev/random or /dev/urandom? > > I suspect that /dev/urandom may be the better choice, however. /dev/urandom makes more sense. /dev/random will block too easily. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris
Re: a small C program to test xdm's /dev/mem reading on your architecture
In article <[EMAIL PROTECTED]> Branden writes: >> I can't believe he actually intends to keep it like this.. >I'm going to #define DEV_RANDOM /dev/random for Linux systems. And Debian Hurd? Or does the Hurd not have /dev/random or /dev/urandom? I suspect that /dev/urandom may be the better choice, however. Jonathan.
Re: a small C program to test xdm's /dev/mem reading on your architecture
In article <[EMAIL PROTECTED]> Kusti writes: >I believe the /dev/mem gets read only in systems where no /dev/(u)random >exists. Actually, the standard configuration is that /dev/mem is read. The code to read from /dev/(u)random isn't activated in any situation in the standard upstream X distribution, and given that it contains an error that stops it from compiling[1] I suspect that it has only ever rarely been used. Obviously the correct thing to do is to shift to using /dev/(u)random by default. Jonathan.
Re: a small C program to test xdm's /dev/mem reading on your architecture
[Apologies to readers of debian-sparc, who have already received a copy of this] In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] write: [XDM randomness] >/dev/random? /dev/urandom? You are kidding. This randmomness is used >to create authorisation cookies for X which in my understanding provide >ZERO security. Use plain libc rand() and the security is exactly the same. In the situation where the X session is in practice running over unix sockets (or other configurations where all the data stays local to the machine without being vulnerable to network (or other) sniffing attacks)[1], the cookies in question provide the security that they were designed for - namely requiring a significant proportion of the space available to said cookies to be trawled to be able to send authenticated requests to the X server.[2] Jonathan. [1] Although, said server may be listening for tcpip connections, or those of other protocols to which the attacker can send their requests. [2] Having looked at the code, it is not obvious to me that the entropy produced in said cookies doesn't have a maximum of 32 bits, even if the cookie is longer than that.
Re: a small C program to test xdm's /dev/mem reading on your architecture
> I and the other folks at the X Strike Force need to know the following > things: > > 1) whether or not this program works when you run it without arguments Runs without any problem ("read of /dev/mem returned 1") on PPC Powerbook 1999 "Lombard" (ran it multiple times, before and after sleep mode but not much else happening on it). > 3) if scenario 1) causes problems, whether invoking this program with > the argument "fragile" helps it Tried it anyway, same thing. HTH, Michael
Re: a small C program to test xdm's /dev/mem reading on your architecture
Marcus Brinkmann <[EMAIL PROTECTED]> writes: > You are mistaken. Do yourself a favour and get a book about (pseudo) > random number generators, entropy, hash functions and cryptography. > If you don't start with random numbers, you can turn the numbers upside > down, it won't get any more random than what you started with. There's also a nice comment at the top of drivers/char/random.c that (I assume) Ted Ts'o wrote. It's a nice, succinct explanation of many things regarding linux randomness and randomness in general. --
Re: a small C program to test xdm's /dev/mem reading on your architecture
Hello ! This programm works on 20164 (LX) running Debian/GNU Linux (Woody) 20164 (dual) running Digital Unix (using Compaq C-Compiler) 20264 (XP1000) running Linux Greetings Helge -- Helge Kreutzmann, Dipl.-Phys. [EMAIL PROTECTED] gpg signed mail preferredgpg-key: finger [EMAIL PROTECTED] 64bit GNU powered http://www.itp.uni-hannover.de/~kreutzm Help keep free software "libre": http://www.freepatents.org/ pgpZ0agvw2QKQ.pgp Description: PGP signature
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 09:10:54PM +0200, Marcus Brinkmann wrote: > On Mon, Aug 26, 2002 at 12:50:22PM -0500, Branden Robinson wrote: > > > I can't believe he actually intends to keep it like this.. > > > > I'm going to #define DEV_RANDOM /dev/random for Linux systems. > > That's bad, because that will drain the entropy a lot, and it might > block for a long time, and that for no good reason as I don't think the > magic cookie needs strong cryptographical security (for comparison: The > secret key of a public key cryptography key pair should be created using > /dev/random, while for session keys /dev/urandom is good enough). /dev/random? /dev/urandom? You are kidding. This randmomness is used to create authorisation cookies for X which in my understanding provide ZERO security. Use plain libc rand() and the security is exactly the same. Richard
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 02:44:26PM -0500, Branden Robinson wrote: > On Mon, Aug 26, 2002 at 03:28:18PM -0400, Jeff Sheinberg wrote: > > Why does anyone need to read megabytes of urandom? > > Nobody does. Or, at least, xdm doesn't. Markus is opining without the > benefit of having checked the facts. Uh, I never, ever said that xdm would read megabytes from any /dev/ but /dev/mem. Some people have too much phantasies. Thanks, Brandon, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 02:43:09PM -0500, Branden Robinson wrote: > xdm doesn't read the same amount of data when it's reading from a > (presumably) entropic device node. I didn't assume that. > It reads eight size_t's. Surely that is not excessive. It's eight size_t's good entropy wasted for no important use still. In some environments, good entropy is really hard to get at. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 03:28:18PM -0400, Jeff Sheinberg wrote: > Why does anyone need to read megabytes of urandom? Nobody does. Or, at least, xdm doesn't. Markus is opining without the benefit of having checked the facts. -- G. Branden Robinson| What influenced me to atheism was Debian GNU/Linux | reading the Bible cover to cover. [EMAIL PROTECTED] | Twice. http://people.debian.org/~branden/ | -- J. Michael Straczynski pgpU4eC5jnJbD.pgp Description: PGP signature
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 09:10:54PM +0200, Marcus Brinkmann wrote: > On Mon, Aug 26, 2002 at 12:50:22PM -0500, Branden Robinson wrote: > > > I can't believe he actually intends to keep it like this.. > > > > I'm going to #define DEV_RANDOM /dev/random for Linux systems. > > That's bad, because that will drain the entropy a lot, xdm doesn't read the same amount of data when it's reading from a (presumably) entropic device node. It reads eight size_t's. Surely that is not excessive. Please read the thread. -- G. Branden Robinson| Measure with micrometer, Debian GNU/Linux | mark with chalk, [EMAIL PROTECTED] | cut with axe, http://people.debian.org/~branden/ | hope like hell. pgp9Prc2nJkIo.pgp Description: PGP signature
Re: a small C program to test xdm's /dev/mem reading on your architecture
Marcus Brinkmann writes: > On Mon, Aug 26, 2002 at 12:50:22PM -0500, Branden Robinson wrote: > > > I can't believe he actually intends to keep it like this.. > > > > I'm going to #define DEV_RANDOM /dev/random for Linux systems. > > That's bad, because that will drain the entropy a lot, and it might > block for a long time, and that for no good reason as I don't think the > magic cookie needs strong cryptographical security (for comparison: The > secret key of a public key cryptography key pair should be created using > /dev/random, while for session keys /dev/urandom is good enough). Here is how I create the magic cookie in my ~/.xserverrc shell script, cookie () { dd if=/dev/urandom 2>/dev/null bs=16 count=1 | od -x | awk ' NR==1 { print $2 $3 $4 $5 $6 $7 $8 $9 } ' } e.g., $ cookie a0de8e57919780bbc5ff16e66e1af2a9 and I use it in .xserverrc like this, mcookie=`cookie` # Add this cookie to the X server auth file. xauth -f "${auth}" \ -v add "0.0.0.0:${xdpnum}" "${access}" "${mcookie}" # Add necessary new display entries to .Xauthority file. xauth -v add "${eth0}:${xdpnum}" "${access}" "${mcookie}" xauth -v add "${host}:${xdpnum}" "${access}" "${mcookie}" xauth -v add "${host}/unix:${xdpnum}" "${access}" "${mcookie}" Why does anyone need to read megabytes of urandom? If it really is random, then 16 bytes should be enough. -- Jeff Sheinberg
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 08:16:06PM +0100, Matthew Wilcox wrote: > On Mon, Aug 26, 2002 at 09:10:54PM +0200, Marcus Brinkmann wrote: > > Also, reading /dev/mem doesn't sound very secure at all (even if it works) > > because the patterns in the memory of a computer are probably predictable > > and a lot of information can be observed from the outside (which processes > > are running etc). > > why do you assume that xdm uses the raw result from /dev/mem? I don't. That would be obviously too foolish. It would also not make sense by Branden's original mail which clearly stated that xdm can read several megabytes from /dev/mem. I assume they do this because they know that /dev/mem doesn't contain much entropy, and as such they try to get enough randomness squeezed out of it by reading more and more of it. This is a dubious approach. > running, > say, md5 over the results would give you something as close to random > as i doubt you could find a difference. You are mistaken. Do yourself a favour and get a book about (pseudo) random number generators, entropy, hash functions and cryptography. If you don't start with random numbers, you can turn the numbers upside down, it won't get any more random than what you started with. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 09:10:54PM +0200, Marcus Brinkmann wrote: > Also, reading /dev/mem doesn't sound very secure at all (even if it works) > because the patterns in the memory of a computer are probably predictable > and a lot of information can be observed from the outside (which processes > are running etc). why do you assume that xdm uses the raw result from /dev/mem? running, say, md5 over the results would give you something as close to random as i doubt you could find a difference. -- Revolutions do not require corporate support.
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 12:50:22PM -0500, Branden Robinson wrote: > > I can't believe he actually intends to keep it like this.. > > I'm going to #define DEV_RANDOM /dev/random for Linux systems. That's bad, because that will drain the entropy a lot, and it might block for a long time, and that for no good reason as I don't think the magic cookie needs strong cryptographical security (for comparison: The secret key of a public key cryptography key pair should be created using /dev/random, while for session keys /dev/urandom is good enough). Also, reading /dev/mem doesn't sound very secure at all (even if it works) because the patterns in the memory of a computer are probably predictable and a lot of information can be observed from the outside (which processes are running etc). Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: a small C program to test xdm's /dev/mem reading on your architecture
> I'm wondering if XFree86 considers it worth the trouble. I have no doubt that a tested, cross-platform patch will be accepted. Non-portable patches are sometimes considered more trouble than they are worth. (You should at least consider Linux, the three Free BSDs, Solaris, Lynx and OS X, on all supported platforms.) Juliusz
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 10:23:06AM -0400, Joey Hess wrote: > matthew green wrote: > > bad ideas often hang around for a long time. the only surprising > > thing to me is how long this one has taken to surface... > > Perhaps Branden is gathering information about what a bad idea this > really is, to show upstream the error of their ways. Well, I hadn't reached that conclusion a priori. > I can't believe he actually intends to keep it like this.. I'm going to #define DEV_RANDOM /dev/random for Linux systems. -- G. Branden Robinson|You should try building some of the Debian GNU/Linux |stuff in main that is [EMAIL PROTECTED] |modern...turning on -Wall is like http://people.debian.org/~branden/ |turning on the pain. -- James Troup pgp615LaAm68a.pgp Description: PGP signature
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 11:13:08AM +0200, Wichert Akkerman wrote: > Previously Kimmo K. I. Surakka wrote: > > I think the "safe" way of getting random data without a decent random > > source would be to write one. This, however, would be more that just > > a small patch. > > There is existing code to generate randomness from userland, look at > what current OpenSSH does for example. I'm wondering if XFree86 considers it worth the trouble. -- G. Branden Robinson| The software said it required Debian GNU/Linux | Windows 3.1 or better, so I [EMAIL PROTECTED] | installed Linux. http://people.debian.org/~branden/ | pgpx09efXqI1L.pgp Description: PGP signature
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 10:34:45AM +0200, Thomas Horsten wrote: > > On Mon, Aug 26, 2002 at 05:04:26PM +1000, matthew green wrote: > > > actually, i hadn't, but there wasn't very much there besides the > > > fact that people found it was xdm reading /dev/mem and a small > > > patch for debian to enable /dev/random (i'd suggest /dev/urandom). > > > > If any of these it should be /dev/random. /dev/urandom would stall most of > > the time on headless systems, which is the only place where I (and very > > likely a lot of other people too) run xdm in the first place. > > No, it's random that stalls if the entropy pool is not full. I'm going to use /dev/random, for the reasons explained in the thread which no one read. :) -- G. Branden Robinson| It just seems to me that you are Debian GNU/Linux | willfully entering an arse-kicking [EMAIL PROTECTED] | contest with a monstrous entity http://people.debian.org/~branden/ | that has sixteen legs and no arse. pgpraT0cWmxQl.pgp Description: PGP signature
Re: a small C program to test xdm's /dev/mem reading on your architecture
[EMAIL PROTECTED]:~/tmp$ sudo ./test Reading data from /dev/mem... read #2 of 8192 bytes read #3 of 8192 bytes read #4 of 8192 bytes read #5 of 8192 bytes read #6 of 8192 bytes read #7 of 8192 bytes read #8 of 8192 bytes read #9 of 8192 bytes read #10 of 8192 bytes read #11 of 8192 bytes read #12 of 8192 bytes read #13 of 8192 bytes read #14 of 8192 bytes read #15 of 8192 bytes read #16 of 8192 bytes read #17 of 8192 bytes read #18 of 8192 bytes read #19 of 8192 bytes read #20 of 8192 bytes read #21 of 8192 bytes read #22 of 8192 bytes read #23 of 8192 bytes read #24 of 8192 bytes read #25 of 8192 bytes read #26 of 8192 bytes read #27 of 8192 bytes read #28 of 8192 bytes read #29 of 8192 bytes read #30 of 8192 bytes read #31 of 8192 bytes read #32 of 8192 bytes read #33 of 8192 bytes read #34 of 8192 bytes read #35 of 8192 bytes read #36 of 8192 bytes read #37 of 8192 bytes read #38 of 8192 bytes read #39 of 8192 bytes read #40 of 8192 bytes read #41 of 8192 bytes read #42 of 8192 bytes read #43 of 8192 bytes read #44 of 8192 bytes read #45 of 8192 bytes read #46 of 8192 bytes read #47 of 8192 bytes read #48 of 8192 bytes read #49 of 8192 bytes read #50 of 8192 bytes read #51 of 8192 bytes read #52 of 8192 bytes read #53 of 8192 bytes read #54 of 8192 bytes read #55 of 8192 bytes read #56 of 8192 bytes read #57 of 8192 bytes read #58 of 8192 bytes read #59 of 8192 bytes read #60 of 8192 bytes read #61 of 8192 bytes read #62 of 8192 bytes read #63 of 8192 bytes read #64 of 8192 bytes read #65 of 8192 bytes read #66 of 8192 bytes read #67 of 8192 bytes read #68 of 8192 bytes read #69 of 8192 bytes read #70 of 8192 bytes read #71 of 8192 bytes read #72 of 8192 bytes read #73 of 8192 bytes read #74 of 8192 bytes read #75 of 8192 bytes read #76 of 8192 bytes read #77 of 8192 bytes read #78 of 8192 bytes read #79 of 8192 bytes read #80 of 8192 bytes read #81 of 8192 bytes read #82 of 8192 bytes read #83 of 8192 bytes read #84 of 8192 bytes read #85 of 8192 bytes read #86 of 8192 bytes read #87 of 8192 bytes read #88 of 8192 bytes read #89 of 8192 bytes read #90 of 8192 bytes read #91 of 8192 bytes read #92 of 8192 bytes read #93 of 8192 bytes read #94 of 8192 bytes read #95 of 8192 bytes read #96 of 8192 bytes read #97 of 8192 bytes read #98 of 8192 bytes read #99 of 8192 bytes read #100 of 8192 bytes read #101 of 8192 bytes read #102 of 8192 bytes read #103 of 8192 bytes read #104 of 8192 bytes read #105 of 8192 bytes read #106 of 8192 bytes read #107 of 8192 bytes read #108 of 8192 bytes read #109 of 8192 bytes read #110 of 8192 bytes read #111 of 8192 bytes read #112 of 8192 bytes read #113 of 8192 bytes read #114 of 8192 bytes read #115 of 8192 bytes read #116 of 8192 bytes read #117 of 8192 bytes read #118 of 8192 bytes read #119 of 8192 bytes read #120 of 8192 bytes read #121 of 8192 bytes read #122 of 8192 bytes read #123 of 8192 bytes read #124 of 8192 bytes read #125 of 8192 bytes read #126 of 8192 bytes read #127 of 8192 bytes read #128 of 8192 bytes read #129 of 8192 bytes read #130 of 8192 bytes read #131 of 8192 bytes read #132 of 8192 bytes read #133 of 8192 bytes read #134 of 8192 bytes read #135 of 8192 bytes read #136 of 8192 bytes read #137 of 8192 bytes read #138 of 8192 bytes read #139 of 8192 bytes read #140 of 8192 bytes read #141 of 8192 bytes read #142 of 8192 bytes read #143 of 8192 bytes read #144 of 8192 bytes read #145 of 8192 bytes read #146 of 8192 bytes read #147 of 8192 bytes read #148 of 8192 bytes read #149 of 8192 bytes read #150 of 8192 bytes read #151 of 8192 bytes read #152 of 8192 bytes read #153 of 8192 bytes read #154 of 8192 bytes read #155 of 8192 bytes read #156 of 8192 bytes read #157 of 8192 bytes read #158 of 8192 bytes read #159 of 8192 bytes read #160 of 8192 bytes read #161 of 8192 bytes read #162 of 8192 bytes read #163 of 8192 bytes read #164 of 8192 bytes read #165 of 8192 bytes read #166 of 8192 bytes read #167 of 8192 bytes read #168 of 8192 bytes read #169 of 8192 bytes read #170 of 8192 bytes read #171 of 8192 bytes read #172 of 8192 bytes read #173 of 8192 bytes read #174 of 8192 bytes read #175 of 8192 bytes read #176 of 8192 bytes read #177 of 8192 bytes read #178 of 8192 bytes read #179 of 8192 bytes read #180 of 8192 bytes read #181 of 8192 bytes read #182 of 8192 bytes read #183 of 8192 bytes read #184 of 8192 bytes read #185 of 8192 bytes read #186 of 8192 bytes read #187 of 8192 bytes read #188 of 8192 bytes read #189 of 8192 bytes read #190 of 8192 bytes read #191 of 8192 bytes read #192 of 8192 bytes read #193 of 8192 bytes read #194 of 8192 bytes read #195 of 8192 bytes read #196 of 8192 bytes read #197 of 8192 bytes read #198 of 8192 bytes read #199 of 8192 bytes read #200 of 8192 bytes read #201 of 8192 bytes read #202 of 8192 bytes read #203 of
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, 2002-08-26 at 08:20, Branden Robinson wrote: > > I need people with root on machines of your given architecture to > compile and run the attached C program. It consists of code borrowed > from xdm's genauth.c program. > Branden, In the hope that this report is useful to you, I compiled your program readmem.c on my Alpha Personal WorkStation 433, and ran it as root. No problems or crashes. It ended with: read #1024 of 16384 bytes done with read of /dev/mem (returned 1). sumFile() succeeded. So, I guess this machine is lucky :-) For completeness' sake: Alpha PWS 433 576 MB memory + 2 MB L3-cache Voodoo3 3000 PCI, Symbios Logic 53c875, SB Live running Debian Sid (unstable). Ciao, Dannis.
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 09:06:00AM -0400, Carlos O'Donell wrote: > Done. I've submitted the output for HPPA boxes running 32 and 64-bit > kernels. Looks like they pass without any problem. I'll pass on the yes, but it may well crash them. some parts of /dev/mem map random IO addresses which may not take kindly to being read in an unprovoked manner. -- Revolutions do not require corporate support.
Re : a small C program to test xdm's /dev/mem reading on your architecture
Happy to help...works fine on both my systems. ...testing on Celery 450Mhz, Unstable read #1023 of 8192 bytes read #1024 of 8192 bytes done with read of /dev/mem (returned 1). sumFile() succeeded. ...and just for the record with the fragile arg : read #1023 of 8192 bytes read #1024 of 8192 bytes done with read of (fragile) /dev/mem (returned 1). sumFile() succeeded. ...and another run on P3 750Mhz, Unstable read #1023 of 8192 bytes read #1024 of 8192 bytes done with read of /dev/mem (returned 1). sumFile() succeeded. ...and with the fragile arg : read #1023 of 8192 bytes read #1024 of 8192 bytes done with read of (fragile) /dev/mem (returned 1). sumFile() succeeded. Cheers Rich Wale.
Re: a small C program to test xdm's /dev/mem reading on your architecture
matthew green wrote: > bad ideas often hang around for a long time. the only surprising > thing to me is how long this one has taken to surface... Perhaps Branden is gathering information about what a bad idea this really is, to show upstream the error of their ways. I can't believe he actually intends to keep it like this.. FWIW, the program doesn't crash my old 486, which is a bit suprising, I know that this kind of thing is capable of crashing ISA systems. -- see shy jo
Re: a small C program to test xdm's /dev/mem reading on your architecture
on my pc164lx running woody 2.4.18 kernel with 512M mem. read #1022 of 16384 bytes read #1023 of 16384 bytes read #1024 of 16384 bytes done with read of /dev/mem (returned 1). sumFile() succeeded. ganesha:~# cat /proc/cpuinfo cpu : Alpha cpu model : EV56 cpu variation : 7 cpu revision: 0 cpu serial number : system type : EB164 system variation: LX164 system revision : 0 system serial number: cycle frequency [Hz]: 5 timer frequency [Hz]: 1024.00 page size [bytes] : 8192 phys. address bits : 40 max. addr. space # : 127 BogoMIPS: 1057.24 kernel unaligned acc: 0 (pc=0,va=0) user unaligned acc : 0 (pc=0,va=0) platform string : Digital AlphaPC 164LX 533 MHz cpus detected : 1 on my pc164ux woody 2.4.18 kernel, 512M memory, same result cpu : Alpha cpu model : EV56 cpu variation : 0 cpu revision: 0 cpu serial number : Linux_is_Great! system type : Ruffian system variation: 0 system revision : 0 system serial number: MILO-/aux/KERNE cycle frequency [Hz]: 6 timer frequency [Hz]: 1024.00 page size [bytes] : 8192 phys. address bits : 40 max. addr. space # : 127 BogoMIPS: 1187.96 kernel unaligned acc: 0 (pc=0,va=0) user unaligned acc : 0 (pc=0,va=0) platform string : N/A cpus detected : 0 On Mon, 26 Aug 2002 01:20:33 -0500 Branden Robinson <[EMAIL PROTECTED]> wrote: > The long story, for those interested: > > http://lists.debian.org/debian-x/2002/debian-x-200208/msg00091.html > > (and read the whole thread) > > The short story: > > I need people with root on machines of your given architecture to > compile and run the attached C program. It consists of code borrowed > from xdm's genauth.c program. > > The X Strike Force is trying to determine for which architectures it's a > bad idea to read several megabytes of data sequentially from /dev/mem, > because this is exactly what XDM currently does when generating an > XDM-AUTHORIZATION-1 cookie. > > Be warned: on at least some architectures (notably IA-64), this sort of > read has been known to cause untrapped machine checks (a.k.a., lockups > or spontaneous reboots). Arguably the kernel should trap this sort of > nonsense, so you may be in the mood to file a bug against "kernel" after > running this program. > > I and the other folks at the X Strike Force need to know the following > things: > > 1) whether or not this program works when you run it without arguments > 2) if scenario 1) causes problems, what the last line of output was > 3) if scenario 1) causes problems, whether invoking this program with > the argument "fragile" helps it > 4) if scenario 3) causes problems, what the last line of output was > > Remember, this program must be run as root. If normal users can read > from /dev/mem on your machine, you're in trouble. :) > > -- > G. Branden Robinson| No math genius, eh? Then > perhaps Debian GNU/Linux | you could explain to me > where you [EMAIL PROTECTED] | got these... > PENROSE TILES! http://people.debian.org/~branden/ | -- Stephen R. > Notley >
Re: a small C program to test xdm's /dev/mem reading on your architecture
Branden, > The long story, for those interested: > http://lists.debian.org/debian-x/2002/debian-x-200208/msg00091.html > (and read the whole thread) > The short story: > I need people with root on machines of your given architecture to > compile and run the attached C program. It consists of code borrowed > from xdm's genauth.c program. > Done. I've submitted the output for HPPA boxes running 32 and 64-bit kernels. Looks like they pass without any problem. I'll pass on the test results for an older 715/50 box (the other boxes were an A500 and C3K). Secondly, I will open a big can a whoopass on anyone else I see complaining about /dev/mem reading without providng a patch >:) Branden is merely asking you to _test_ something. c.
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Monday 26 Aug 2002 7:20 am, Branden Robinson wrote: > I need people with root on machines of your given architecture to > compile and run the attached C program. It consists of code borrowed > from xdm's genauth.c program. Runs OK on hppa (712/80, hppa1.1, Woody).
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Monday 26 August 2002 02:20 am, Branden Robinson wrote: > I and the other folks at the X Strike Force need to know the following > things: > > 1) whether or not this program works when you run it without arguments > 2) if scenario 1) causes problems, what the last line of output was > 3) if scenario 1) causes problems, whether invoking this program with > the argument "fragile" helps it > 4) if scenario 3) causes problems, what the last line of output was It runs just fine on my 533 MHz Enorex AlphaPC (164SX, I think). Bob
Re: a small C program to test xdm's /dev/mem reading on your architecture
I tested it on an R4600SC (SGI Indy) running Debian unstable: indy 2.4.17-r4k-ip22 I ran it twice with and without the fragile argument. No arguments gave: read #66 of 8192 bytes the first time, read #73 of 8192 bytes the second time. With fagile argument: Reading data from (fragile) /dev/mem... both times.
Re: a small C program to test xdm's /dev/mem reading on your architecture
matthew green <[EMAIL PROTECTED]> writes: > my point is that on modern systems we simply should not read > from /dev/mem for these purposes _ever_. It would make some sense to read all the physical memory in the machine. Unfortunately, I'm not aware of any reasonably way to do that. Reading /dev/mem does something quite different. I was about to put /dev/mem reading into my own seed-generation program a while back, but then [EMAIL PROTECTED] explained to me that it was a really bad idea. A safer thing to do is to read the raw partitions on which /var, /tmp and perhaps also swap lives, but I gave up that plan after I read the GNU df source code looking for a way to get to a device, given a directory (such as /var) in the filesystem. But programs such as xdm should not do things like that, regular generation of cookies etc should use some decent randomness generator provided with the operating system, be that /dev/urandom or prngd or whatever. /Niels
Re: a small C program to test xdm's /dev/mem reading on your architecture
Previously Kimmo K. I. Surakka wrote: > I think the "safe" way of getting random data without a decent random > source would be to write one. This, however, would be more that just > a small patch. There is existing code to generate randomness from userland, look at what current OpenSSH does for example. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: a small C program to test xdm's /dev/mem reading on your architecture
> On Mon, Aug 26, 2002 at 05:04:26PM +1000, matthew green wrote: > > actually, i hadn't, but there wasn't very much there besides the > > fact that people found it was xdm reading /dev/mem and a small > > patch for debian to enable /dev/random (i'd suggest /dev/urandom). > > If any of these it should be /dev/random. /dev/urandom would stall most of > the time on headless systems, which is the only place where I (and very > likely a lot of other people too) run xdm in the first place. No, it's random that stalls if the entropy pool is not full. // Thomas
RE: a small C program to test xdm's /dev/mem reading on your architecture
Filip Van Raemdonck <[EMAIL PROTECTED]> wrote: > On Mon, Aug 26, 2002 at 05:04:26PM +1000, matthew green wrote: > > actually, i hadn't, but there wasn't very much there besides the > > fact that people found it was xdm reading /dev/mem and a small > > patch for debian to enable /dev/random (i'd suggest /dev/urandom). > > If any of these it should be /dev/random. /dev/urandom would stall most of > the time on headless systems, which is the only place where I (and very > likely a lot of other people too) run xdm in the first place. You're mistaken here: /dev/random blocks, /dev/urandom doesn't. Julian.
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, 26 Aug 2002 17:04:26 +1000 "matthew green" <[EMAIL PROTECTED]> wrote: > actually, i hadn't, but there wasn't very much there besides the > fact that people found it was xdm reading /dev/mem and a small > patch for debian to enable /dev/random (i'd suggest /dev/urandom). > > my point is that on modern systems we simply should not read > from /dev/mem for these purposes _ever_. so far it has shown to > be unsafe on at least: I believe the /dev/mem gets read only in systems where no /dev/(u)random exists. There really are such systems. Agreed, reading raw memory is an unstable and dangerous way of getting enthropy, but xdm needs some way of getting it. If I understood the thread correctly, the preferred way indeed is the /dev/(u)random way. Still, the unlucky ones with no /dev/(u)random should not be forgotten. I think the "safe" way of getting random data without a decent random source would be to write one. This, however, would be more that just a small patch. A simple random number generator doesn't do, since it's all too predictable. One approach could be using two separate threads to read the same rnd-generator, so the system's scheduler would make the resulting data sequence unpredictable. However, I believe this is not very portable approach either: it is only possible, if threads are. And even if the system supports mt-programming, how can we be sure that the thread switching happens unpredictably? So, a better solution is needed. Probably one even exists. Just my 2 cents, Kusti
Re: a small C program to test xdm's /dev/mem reading on your architecture
Hi, On Mon, Aug 26, 2002 at 05:04:26PM +1000, matthew green wrote: > > > > why don't you use /dev/urandom if it exists, as it does on pretty > > > much all modern UNIX platforms? > > > > I see you haven't read the thread. > > > actually, i hadn't, but there wasn't very much there besides the > fact that people found it was xdm reading /dev/mem and a small > patch for debian to enable /dev/random (i'd suggest /dev/urandom). If any of these it should be /dev/random. /dev/urandom would stall most of the time on headless systems, which is the only place where I (and very likely a lot of other people too) run xdm in the first place. Regards, Filip -- shorty: its not exactly intuitive, since women dont follow boolean logic or any logic known to man, for that matter
Re: a small C program to test xdm's /dev/mem reading on your architecture
Hello ! I'll run it later on different alphas, but I checked it on a ppc-machine running AIX if this is of any interest to you: [EMAIL PROTECTED]: /root # ./readmem.aix.x Reading data from /dev/mem... read #2 of 8192 bytes ... read #1024 of 8192 bytes done with read of /dev/mem (returned 1). sumFile() succeeded. There are 1023 lines starting with "read" (starting with number 2). Greetings Helge -- Helge Kreutzmann, Dipl.-Phys. [EMAIL PROTECTED] gpg signed mail preferredgpg-key: finger [EMAIL PROTECTED] 64bit GNU powered http://www.itp.uni-hannover.de/~kreutzm Help keep free software "libre": http://www.freepatents.org/ pgpcQW22o9a7Z.pgp Description: PGP signature
re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 04:28:38PM +1000, matthew green wrote: > wow, this is such a bad idea. It originated upstream. mmm, xdm. In fact, judging by CVS logs it has been in xdm's source for many, many years. bad ideas often hang around for a long time. the only surprising thing to me is how long this one has taken to surface... > why don't you use /dev/urandom if it exists, as it does on pretty > much all modern UNIX platforms? > > *shudder* I see you haven't read the thread. actually, i hadn't, but there wasn't very much there besides the fact that people found it was xdm reading /dev/mem and a small patch for debian to enable /dev/random (i'd suggest /dev/urandom). my point is that on modern systems we simply should not read from /dev/mem for these purposes _ever_. so far it has shown to be unsafe on at least: - ia64 - arm - mips - ultrasparc i'm sure there are more... i don't see the purpose in running the program you posted - we shouldn't care whether it works, just don't do it. i'm going to patch NetBSD xsrc shortly to fix this if it isn't already... .mrg.
Re: a small C program to test xdm's /dev/mem reading on your architecture
HP rx4610 (4x Itanium), Debian unstable, 2.4.18-itanium-smp Works without problems HP i2000 (Itanium), Debian unstable, 2.4.18-itanium Machine hangs after read #40; works with "fragile" DEC UDB (Alpha 21066), Debian unstable, 2.4.6 Works without problems I do think that blindly reading /dev/mem is a bad idea though ;) Matt On Mon, Aug 26, 2002 at 01:20:33AM -0500, Branden Robinson wrote: > The long story, for those interested: > > http://lists.debian.org/debian-x/2002/debian-x-200208/msg00091.html > > (and read the whole thread) > > The short story: > > I need people with root on machines of your given architecture to > compile and run the attached C program. It consists of code borrowed > from xdm's genauth.c program. > > The X Strike Force is trying to determine for which architectures it's a > bad idea to read several megabytes of data sequentially from /dev/mem, > because this is exactly what XDM currently does when generating an > XDM-AUTHORIZATION-1 cookie. > > Be warned: on at least some architectures (notably IA-64), this sort of > read has been known to cause untrapped machine checks (a.k.a., lockups > or spontaneous reboots). Arguably the kernel should trap this sort of > nonsense, so you may be in the mood to file a bug against "kernel" after > running this program. > > I and the other folks at the X Strike Force need to know the following > things: > > 1) whether or not this program works when you run it without arguments > 2) if scenario 1) causes problems, what the last line of output was > 3) if scenario 1) causes problems, whether invoking this program with > the argument "fragile" helps it > 4) if scenario 3) causes problems, what the last line of output was > > Remember, this program must be run as root. If normal users can read > from /dev/mem on your machine, you're in trouble. :) > > -- > G. Branden Robinson| No math genius, eh? Then perhaps > Debian GNU/Linux | you could explain to me where you > [EMAIL PROTECTED] | got these... PENROSE TILES! > http://people.debian.org/~branden/ | -- Stephen R. Notley
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, 26 Aug 2002, Branden Robinson wrote: > 1) whether or not this program works when you run it without arguments . . read #1023 of 16384 bytes read #1024 of 16384 bytes done with read of /dev/mem (returned 1). sumFile() succeeded. Behaves the same with fragile, tested on two pci-based alphas ("noname", 21066, 96 and 128 MB RAM) from '93. Hope this is correct. :) /daniel
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 04:28:38PM +1000, matthew green wrote: > wow, this is such a bad idea. It originated upstream. In fact, judging by CVS logs it has been in xdm's source for many, many years. > why don't you use /dev/urandom if it exists, as it does on pretty > much all modern UNIX platforms? > > *shudder* I see you haven't read the thread. -- G. Branden Robinson| Debian GNU/Linux | De minimis non curat lex. [EMAIL PROTECTED] | http://people.debian.org/~branden/ | pgpJR3tsWdw5D.pgp Description: PGP signature
re: a small C program to test xdm's /dev/mem reading on your architecture
Be warned: on at least some architectures (notably IA-64), this sort of read has been known to cause untrapped machine checks (a.k.a., lockups or spontaneous reboots). Arguably the kernel should trap this sort of nonsense, so you may be in the mood to file a bug against "kernel" after running this program. wow, this is such a bad idea. the kernel *can't* trap that sort of thing in a lot of cases. simply the hardware goes catatonic. this is true of ultrasparc machines as well. you may also access some random "device" memory causing it do do something unexpected. "read" can be very destructive of device state... why don't you use /dev/urandom if it exists, as it does on pretty much all modern UNIX platforms? *shudder* .mrg.
a small C program to test xdm's /dev/mem reading on your architecture
The long story, for those interested: http://lists.debian.org/debian-x/2002/debian-x-200208/msg00091.html (and read the whole thread) The short story: I need people with root on machines of your given architecture to compile and run the attached C program. It consists of code borrowed from xdm's genauth.c program. The X Strike Force is trying to determine for which architectures it's a bad idea to read several megabytes of data sequentially from /dev/mem, because this is exactly what XDM currently does when generating an XDM-AUTHORIZATION-1 cookie. Be warned: on at least some architectures (notably IA-64), this sort of read has been known to cause untrapped machine checks (a.k.a., lockups or spontaneous reboots). Arguably the kernel should trap this sort of nonsense, so you may be in the mood to file a bug against "kernel" after running this program. I and the other folks at the X Strike Force need to know the following things: 1) whether or not this program works when you run it without arguments 2) if scenario 1) causes problems, what the last line of output was 3) if scenario 1) causes problems, whether invoking this program with the argument "fragile" helps it 4) if scenario 3) causes problems, what the last line of output was Remember, this program must be run as root. If normal users can read from /dev/mem on your machine, you're in trouble. :) -- G. Branden Robinson| No math genius, eh? Then perhaps Debian GNU/Linux | you could explain to me where you [EMAIL PROTECTED] | got these... PENROSE TILES! http://people.debian.org/~branden/ | -- Stephen R. Notley #include #include #include #include #include #include #include #define FILE_LIMIT 1024 static int sumFile (char *name, long sum[2], int dofragile) { longbuf[1024*2]; int cnt; int fd; int loops; int reads; int i; int ret_status = 0; fd = open (name, O_RDONLY); if (fd < 0) { fprintf(stderr, "Cannot open randomFile \"%s\" (%s)\n", name, strerror(errno)); return 0; } if (dofragile) { if (strcmp(name, "/dev/mem") == 0) lseek (fd, (off_t) 0x10, SEEK_SET); } reads = FILE_LIMIT; sum[0] = 0; sum[1] = 0; while ((cnt = read (fd, (char *) buf, sizeof (buf))) > 0 && --reads > 0) { printf("read #%d of %d bytes \n", (FILE_LIMIT - reads + 1), sizeof (buf)); loops = cnt / (2 * sizeof (long)); for (i = 0; i < loops; i+= 2) { sum[0] += buf[i]; sum[1] += buf[i+1]; ret_status = 1; } } if (cnt < 0) fprintf(stderr, "Cannot read randomFile \"%s\" (%s)\n", name, strerror(errno)); close (fd); return ret_status; } int main(int argc, char *argv[]) { int status; int dofragile = 0; long checksum[2]; char *filename = "/dev/mem"; if (argv[1] != NULL && (strncmp(argv[1], "fragile", 7) == 0)) { dofragile = 1; } printf("Reading data from %s%s...\n", (dofragile ? "(fragile) " : ""), filename); status = sumFile(filename, checksum, dofragile); printf("done with read of %s%s (returned %d).\n", (dofragile ? "(fragile) " : ""), filename, status); printf("sumFile() %s.\n", (status ? "succeeded" : "failed" )); exit(0); } pgpbJVaP52tld.pgp Description: PGP signature