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
FW: a small C program to test xdm's /dev/mem reading on your arch itecture
OK folks, the banter is getting excessive. I'll have to bail if the dialog can't be kept more point to point instead of broadcast. [EMAIL PROTECTED] -Original Message- From: Marcus Brinkmann To: [EMAIL PROTECTED]; debian-x@lists.debian.org Sent: 8/26/02 3:59 PM Subject: 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 pgpflELhmC3Qe.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. pgpXes5PcCmwz.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/
BUSINESS RELATIONSHIP
CAPT. PAUL DIMANGO. TEL. 27 73 234 9108. FAX 27 72 486 3248. Dear Sir, URGENT INVESTMENT OFFER I know you will be surprise to receive this email from me, but please this letter is a request from someone in dare need of assistance. I Capt. PAUL DIMANGO from Angola, a personal aide to the late Jonas Savimbi of UNITA Angola who was ambushed and killed on Friday 22 of February 2002. I got your name and address from a business desk chamber of commerce and industry in Johannesburg South Africa. I decided to solicit for your business assistance to transfer the sum of US$26. 5 Million (Twenty Six Million Five Hundred Thousand United State Dollars only) from my Boss safe deposit into your personal or company's account. Before the death of Jonas Savimbi, I was in charge of overseeing his personal finances and the up keep of his family expenses. I have access to most of the money he starched away in a private security firm in South Africa. This was made possible because he entrusted me with the authority to use my name in depositing these funds, which he realized from the sales of Diamond in Angola. This is to avert any suspicion prior to when this money will be used for the purchase of Arms and Ammunitions. Before his death I received on his behalf a payment of US$26.5 Million (Twenty Six Million Five Hundred Thousand Unites State Dollars ) in cash, which I deposited in a vault of private security company here in Johannesburg, South Africa but I deposited the funds as Diplomatic Archival Antique? this I did for my security. I am now living in South Africa, as a political Asylum seeker because the situation in my country is not safe for me to go back as there is bound to be serious power tussle and the fate of UNITA the organization that my late Boss was the head before he was killed. I have made up my mind to divert this money and to make a living out of it, since my former boss and I are the only people who have the knowledge about this last payment. Regulatory law of South Africa does not permit asylum seeker certain financial rights. In view of this, I cannot invest this fund in South Africa hence I am seeking your assistance to move out this money out of South Africa to a foreign country for investment purpose which you are going to be the investment manager. For your assistance and effort, I am prepared to offer you 20% of the total fund while 5% will be set aside for any incidental expenses that will be incurred on the course of this transaction and also we are going to donate 5% to the Charity Organization in your country. Please note that this transaction is 100% risk free as I have made adequate arrangement with a bank Director here that will assist us in moving out the money through a Bank network. The major thing I demand from you is assuring me safety of this money when it finally gets to you. Further information and arrangement will commence as soon as trust; confidence and good working relationship is established between us. I shall be most grateful if you maintain the confidentiality of this matter. Please confirm your interest via above telephone and fax numbers. And your urgent reply will be highly appreciated. Best regards, CAPT. PAUL DIMANGO.
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 pgplHz4js2jgu.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: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
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
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: sparc 5 printing
> >When compiling the kernel on the sun box its possible to use pc style >parports. And then if I remember correctly you can use the same modules: >parport and parport_pc and then print using lp. No, old SPARC's do not have this PC-style hardware. Gruss Steffan
RE: sparc 5 printing
When compiling the kernel on the sun box its possible to use pc style parports. And then if I remember correctly you can use the same modules: parport and parport_pc and then print using lp. I have a printer working on my Ultra10 running debian 2.2r6. Matt -Original Message- From: Simon Ross [mailto:[EMAIL PROTECTED] Sent: Monday, August 26, 2002 6:51 AM To: debian-sparc@lists.debian.org Subject: sparc 5 printing Hello, I'm running Debian woody on a SPARC 5 with kernel 2.4.19. I also run an Intel laptop with Debian woody and kernel 2.4.17. My printer is a Lexmark Optra E310. I have managed to setup and print with the Intel setup. The modules parport, parport_pc and lp worked great! The Optra E310 is also a well supported postscript printer. But I want to move the printer onto the SPARC 5 and use it as a network printer. I've mirrored the setup I had on the Intel box. The only change was using parport_sunbpp instead of parport_pc. parport_pc would not complile due to it not seeing a pc parport on the SPARC. So all is looking ok, prints go into and out of the queue. But nothing gets printed. No lights flash. Nothing. Any ideas what I'm missing?? Anything I should check?? Cheers Simon
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
sparc 5 printing
Hello, I'm running Debian woody on a SPARC 5 with kernel 2.4.19. I also run an Intel laptop with Debian woody and kernel 2.4.17. My printer is a Lexmark Optra E310. I have managed to setup and print with the Intel setup. The modules parport, parport_pc and lp worked great! The Optra E310 is also a well supported postscript printer. But I want to move the printer onto the SPARC 5 and use it as a network printer. I've mirrored the setup I had on the Intel box. The only change was using parport_sunbpp instead of parport_pc. parport_pc would not complile due to it not seeing a pc parport on the SPARC. So all is looking ok, prints go into and out of the queue. But nothing gets printed. No lights flash. Nothing. Any ideas what I'm missing?? Anything I should check?? Cheers Simon signature.asc Description: This is a digitally signed message part
Re: Sound Config on Ultra 1
* Tim Chettle <[EMAIL PROTECTED]> [020826 00:52]: > Hi im getting an error telling me that the sound Driver device cant open > /dev/dsp and that the sound server willcontinue using the null device. > > Can any one point me in the right direction as to how to configure up the > sound support. You might want to try /dev/audio instead.
I can't bootstrap gcc-3.3 on sparc32/woody...
I'm trying to build experimental versions of the gcc suite, see http://gcc.gnu.org, on a sun4m, ie SS20, machine. I have two such ones, one dual SuperSparc-II and one quad ROSS. On both systems I get the following error: stage1/xgcc -Bstage1/ -B/usr/sparc-linux/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H-I. -I. -I/opt/gcc+binutils/gcc/gcc -I/opt/gcc+binutils/gcc/gcc/. -I/opt/gcc+binutils/gcc/gcc/config -I/opt/gcc+binutils/gcc/gcc/../include /opt/gcc+binutils/gcc/gcc/cppfiles.c -o cppfiles.o stage1/xgcc -Bstage1/ -B/usr/sparc-linux/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H-I. -I. -I/opt/gcc+binutils/gcc/gcc -I/opt/gcc+binutils/gcc/gcc/. -I/opt/gcc+binutils/gcc/gcc/config -I/opt/gcc+binutils/gcc/gcc/../include /opt/gcc+binutils/gcc/gcc/cpptrad.c -o cpptrad.o stage1/xgcc -Bstage1/ -B/usr/sparc-linux/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H-I. -I. -I/opt/gcc+binutils/gcc/gcc -I/opt/gcc+binutils/gcc/gcc/. -I/opt/gcc+binutils/gcc/gcc/config -I/opt/gcc+binutils/gcc/gcc/../include /opt/gcc+binutils/gcc/gcc/cpphash.c -o cpphash.o stage1/xgcc -Bstage1/ -B/usr/sparc-linux/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H-I. -I. -I/opt/gcc+binutils/gcc/gcc -I/opt/gcc+binutils/gcc/gcc/. -I/opt/gcc+binutils/gcc/gcc/config -I/opt/gcc+binutils/gcc/gcc/../include /opt/gcc+binutils/gcc/gcc/cpperror.c -o cpperror.o /opt/gcc+binutils/gcc/gcc/cppfiles.c:1168: error: parse error before '%' token /opt/gcc+binutils/gcc/gcc/cppfiles.c:1378: error: syntax error at '#' token /opt/gcc+binutils/gcc/gcc/cppfiles.c:1383: error: syntax error at '#' token /opt/gcc+binutils/gcc/gcc/cppfiles.c:1383: error: syntax error at '#' token /opt/gcc+binutils/gcc/gcc/cppfiles.c:1386: error: syntax error at '#' token /opt/gcc+binutils/gcc/gcc/cppfiles.c:1386: error: syntax error at '#' token /opt/gcc+binutils/gcc/gcc/cppfiles.c:1451:25: warning: null character(s) ignored /opt/gcc+binutils/gcc/gcc/cppfiles.c:1451: confused by earlier errors, bailing out make[2]: *** [cppfiles.o] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory `/opt/gcc+binutils/objdir/gcc' make[1]: *** [stage2_build] Error 2 make[1]: Leaving directory `/opt/gcc+binutils/objdir/gcc' make: *** [bootstrap-lean] Error 2 The thing is that the file cppfiles.c ends on line no 1168, an empty line... This was on a Debian 3.0 (Woody) quad ROSS sun4m system with these packages: binutils 2.12.90.0.1-4 dejagnu1.4.2-1.1 gcc2:2.95.4-14 (Debian prerelease) gcc-2.95 1:2.95.4-7 (Debian prerelease) gnat 3.14p-3 self compiled 2.4.19-rc3 SMP kernel running during build and test Any ideas what is going on? Cheers, /ChJ
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
G'Day from Australia
Hello, We understand you are interested in "genuine" home-based businesses that offer security and peace of mind, as well as an excellent income. If this is the case, we sincerely believe we may have just what you are looking for ... superb incomes from low risk, financially sound companies backed by stable management. Be assured, this is NOT a scam. It is a genuine opportunity that has been fully researched. You will find full details on our web page at: http://x-elle.com (Please note, we have taken particular care to ensure this email is sent to only those who are interested in home-based businesses (or working from home). Despite our efforts, there are always exceptions and you might have received this in error. If this is the case, please accept our sincere apologies. This is a once-off mailing and you will not hear from us again. Thanks.) Kind regards, Pieter and Pam (Living the Dream in sunny Australia !)
Sound Config on Ultra 1
Hi im getting an error telling me that the sound Driver device cant open /dev/dsp and that the sound server willcontinue using the null device. Can any one point me in the right direction as to how to configure up the sound support. Thanks Tim
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/ pgpNHP54rOldi.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
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/ | pgp7FmERy363V.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);
}
pgp1AslsoG9Qu.pgp
Description: PGP signature
