From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Wed, 28 Sep 94 01:13:07 EDT Subject: Linux-Development Digest #236 Linux-Development Digest #236, Volume #2 Wed, 28 Sep 94 01:13:07 EDT Contents: Re: [STATUS] Linus Floppy Driver Development (Jorge Cwik) Re: Not identifying ST-506 drives (was: Re: IDE Hard Drives w/ over 1024 cylinders) (Hamish Coleman) Re: Special Sale On QNX! (Dan Hildebrand) News reader for X11 (Mathias Homann) Could TCP/IP be implemented over SCSI? (myers_lincoln) Q: Adaptec 2842VL Driver? (Geir Magnusson) SMail security hole? (William Beckner) Re: [STATUS] Linus Floppy Driver Development (James Harper) Re: Alpha Linux (Andrew Bulhak) i486 Word length, anyone? (James P. Callison) CFS 1.1.2 Unix encrypting file system source code available (free) (Matt Blaze) ---------------------------------------------------------------------------- From: jorge@laser.satlink.net (Jorge Cwik) Subject: Re: [STATUS] Linus Floppy Driver Development Date: Sun, 25 Sep 94 10:21:06 -0400 niemidc@clark.net (David C. Niemi) writes: > The basic problem is that the floppy drive in no way notifies the > rest of the system when a disk has been inserted. This means that > the floppy drive must be polled periodically so as to notice when > a disk appears. This is not impossible, as a test already exists > to poll the drive when it is in use to detect the disk's removal. > However, as you suspected above, it could have a small but noticeable > effect on system performance. Hmm. I'm pretty sure that the floppy controller does generate an interrupt when a disk is removed, and other one when the disk is inserted. I recall posting the details, when somebody claimed that you must actually try writing to the disk to check the WP bit. Which is also unnecessary, btw. Jorge ------------------------------ From: hamish@zot.apana.org.au (Hamish Coleman) Subject: Re: Not identifying ST-506 drives (was: Re: IDE Hard Drives w/ over 1024 cylinders) Date: 25 Sep 1994 16:31:03 +1000 In <35hu42$r51@cesdis1.gsfc.nasa.gov> becker@cesdis.gsfc.nasa.gov (Donald Becker) writes: >In article <3598s8$e7@peril.zot.apana.org.au>, >Hamish Coleman wrote: >>original probe didnt find a controler, its not worth even trying to detect an >>IDE drive -- thus, for _ages_ now, I have had a patch similar to the following >>in my kernels: >> >>--- hd.orig.c Thu Sep 15 20:37:56 1994 >>+++ hd.c Thu Sep 15 20:42:08 1994 >>@@ -1070,6 +1070,10 @@ >> >> unsigned long hd_init(unsigned long mem_start, unsigned long mem_end) >> { >>+ if ( inb_p(HD_STATUS) == 0xff ) { >>+ return mem_start; >>+ } >>+ printk("hd0: wd1003 interface at 0x%04x, IRQ %i\n",HD_DATA,HD_IRQ); >Caution: not getting 0xff back from an inb() does *not* mean there is a >device at that location. There are many machines (including the laptop I'm >typing on) that return some other value from empty locations. You might >consider that hardware flawed, but it works fine and there is a lot of >machines with this characteristic out there. Yes, I am well aware of the fact that it is not a fool-proof method. I am pretty sure of some things though: firstly, HD_STATUS is not ever likely to contain 0xff - so, if we _do_ get an 0xff from that port, then there is _definitely_ no interface there (or a borken one), secondly: once we have decided that there _might_ be an interface there, the normal current kernel procedures are employed -- ie: if it works now, it should work with that patch. This may make that patch _seem_ silly. I originally needed that patch when I was using a secondary HD controller in one machine, and the same kernel in several machines - any machine without the secondary controller, but booting with the secondary-controller-patches would hang trying to read the partition table from the secondary drive. It is more of way of checking that we can safely say that following printk, because if the test passes, that printk is what the kernel is assuming. -- Use Linux! hamish@zot.apana.org.au |)}>=----------------------- This space to let ----------------------=<{(| ``Life is like a grapefruit ... it's sort of orangey-yellow and dimpled on the outside, wet and squidgy in the middle. It's got pips inside too. Oh, and some people have half a one for breakfast.'' -- Ford Prefect ------------------------------ Crossposted-To: comp.os.linux.development From: danh@qnx.com (Dan Hildebrand) Subject: Re: Special Sale On QNX! Date: Mon, 26 Sep 94 12:17:03 GMT In article , wrote: >Why settle for... This is obviously a forged posting. -- Dan Hildebrand danh@qnx.com QNX Software Systems, Ltd. phone: (613) 591-0931 x204 (voice) 175 Terence Matthews (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8 ------------------------------ From: lemmy@eregion.central.de (Mathias Homann) Subject: News reader for X11 Date: Tue, 27 Sep 1994 15:23:52 GMT Hija, has anyone seen any news readers for X by now? btw, please WITHOUT NNTP!! bye, Mathias ------------------------------ From: lim@vector.gs.tandem.com (myers_lincoln) Subject: Could TCP/IP be implemented over SCSI? Date: Tue, 27 Sep 1994 20:59:47 GMT I read in the SCSI FAQ that two SCSI hosts can share SCSI peripherals on the same bus. Is it possible for these two hosts to send commands to each other? I am asking because I would like to know how viable it would be to add support to Linux for TCP/IP over SCSI, which might be practical for two or three machines which already have SCSI support. I didn't see anything in the SCSI-HOWTO or SCSI FAQ that nixed this idea, except that Linux SCSI devices are associated at boot time and might not handle well a peripheral which is not always ready to serve, which would always be the case of one of a set of computers when booting up. On the lighter side, imagine in addition to Ethernet and SCSInet, having SoundCardNet. Sound Cards would record each other's audio output from across the room. True short range wireless communication, though sleeping in the same building might be difficult. ifconfig /dev/audio up. Hannu, you ready for this? :) Lincoln ------------------------------ From: gmj@crab.pha.jhu.edu (Geir Magnusson) Subject: Q: Adaptec 2842VL Driver? Date: 27 Sep 1994 16:35:58 GMT Sorry to post this here, but this question on c.o.l.h had no results. I know that there is a driver for my Adaptec 2842VL SCSI card. I have searched through sunsite and tsx-11. Does anyone know where I can get it? Thanks geir Geir Magnusson Jr. while (ms--) Dept of Physics and Astronomy { Johns Hopkins University linux++; gmj@crab.pha.jhu.edu } ------------------------------ From: wbeckner@darkstar.rsa.lib.il.us (William Beckner) Crossposted-To: comp.os.linux.help Subject: SMail security hole? Date: 27 Sep 1994 16:02:31 -0500 Everyone - I just had the following forwarded to me from our Internet provider, who had it forwarded to him. [ ***** forwarded mail ***** ] I got this from a student using the machine spectrum@bradley (a linux box used by the amateur radio club), thought you might be interested. -fred -- >;>I'm curious what you mean by security holes. The mail user agent >;>(dmail, elm, pico) shouldn't have enough permission to pose a problem. >;>The mail transport agent (sendmail, smail) is another question. - --No, I don't believe it's elm or whatever agent the people are using to read mail. It's smail itself (I think that's what Linux uses)... For example, if a person puts a .forward into their account, and specifies, say, for example: /foofle as the line in the .forward, rather than looking for a user named "foofle" it will put the text of the letter into the root directory as a file named "foofle". Obviously, this is highly undesireable, and fortunately no one other than myself have noticed it yet. (I mentioned it to Pete, and will be getting in contact with the appropriate Linux newsgroups/lists to notify them of the problem... however, I'd really rather see the problem fixed *before* I make it public knowledge that such a problem exists...) [ ***** end of mail ***** ] I just tried this out (kernel version 1.1.22), and smail DOES do as the above mail message states. Does anybody know what we need to do to plug the hole? Any comments? Thanks! -- ============================================================================= William Beckner - System Manager/SysAdmin wbeckner@darkstar.rsa.lib.il.us Ph : (309) 694-5513 FAX: (309) 694-5297 Resource Sharing Alliance of West Central Illinois, Inc. East Peoria, IL (USA) "Off of Route 24 on the Information Highway" ============================================================================= System Administration - It's a dirty job, but somebody said I had to do it. ------------------------------ Subject: Re: [STATUS] Linus Floppy Driver Development From: loon@ironbark.ucnv.edu.au (James Harper) Date: 24 Sep 1994 12:34:42 GMT Alain Knaff (knaff@ngulu) wrote: : Larry Doolittle (doolitt@recycle.cebaf.gov) wrote: : [auto mounting a floppy as soon as it is inserted] : : This situation cries out for a Kernel hook, and the ability : : to have a floppy_mount_daemon that gets activated when the : : user puts in a floppy (periodic disk-change check?). : Unfortunately, this seems to be impossible to do on PC hardware. : There are no separate disk change and disk presence indicators : available. The disk change indicator gets set when set when no disk is : present in the drive. It isn't cleared when a disk is inserted : however. Only a seek clears it. Thus a program wanting to detect when : a disk is inserted would need to seek endlessly until a disk is : inserted. This would make a rather annoying noise, and would probably : wear off the stepper motor as well. i wrote some code to do this once, basically in order to check if there was a disk in the drive it would switch on the disk drive motor, step the head one track then switch it off again, this would reset the disk change indicator to reflect whether there was a disk in the drive or not. All that could be heard was a little click (ever heard an amiga :) and there would be no need to constantly check the disk drive, once every couple of seconds or whatever would be fine. a problem with this (apart from the fact that the clicking of the disk drive could become anoying) is that pulsing the disk motor on and off could place strain on the starting circuitry or whatever... i know that a common problem with amiga disk drives (this was a while ago) was that the disk motor would refuse to start up... if you would give it a flick with your finger it would spin and all would be fine once more.. and I think that amiga's detect disks in drives in roughly the same way. the other alternative would be to have the disk motor on all the time but again I think this could be undesirable. anyway, those are my thoughts on the matter... LOON ------------------------------ From: acbul1@penfold.cc.monash.edu.au (Andrew Bulhak) Subject: Re: Alpha Linux Date: 26 Sep 1994 07:30:53 GMT Jay Ashworth (jra@zeus.IntNet.net) wrote: : acbul1@penfold.cc.monash.edu.au (Andrew Bulhak) writes: : >: Only if Linux on the Alpha will be a 64-bit-OS. If it will be, I hope : >: that they do not repeat the OSF/1 idiocy of having only 32-bit ints. : A posting in cola about a week ago said that it would be a 32-bit os, with : access to long-longs. Is that Linus' Alpha Linux or the DEC port? -- Andrew Bulhak acb@yoyo.cc.monash.edu.au Remember the good old days, when "spam" on the Net referred to processed meat? ------------------------------ From: callison@mailhost.ecn.uoknor.edu (James P. Callison) Subject: i486 Word length, anyone? Date: 27 Sep 1994 18:00:44 GMT I know this is an incredibly stupid question to most of you, but a programmer I ain't--just a simple country support dude (or something like that). What I need to know is--what is Linux's word length? At least, I think that's what I need to know. Specifically, I'm looking for the value of an apparently-BSD-ish variable called NBPW. I found its counterpart NBBY (Number of Bits per BYte) in the include/bsd/bsd.h file, so I'm assuming that NBPW is Number of Bytes Per Word. Of course, I could be totally wrong--I can't find any reference to NBPW in any of the references I have available... I tried setting it to 32 (since the 486 is a 32-bit processor ), and the program seems to compile fine, but it comes up with a floating point exception during execution. If someone could point me in the right direction, I'd appreciate it. James James P. Callison Microcomputer Coordinator, U of Oklahoma Law Center Callison@midway.ecn.uoknor.edu /\ Callison@aardvark.ucs.uoknor.edu DISCLAIMER: I'm not an engineer, but I play one at work... DISCLAIMER FOR THE ANAL-RETENTIVE: OU Pays me for my opinions on microcomputers, and nothing else. For official opinions, contact the University's legal counsel. ------------------------------ Crossposted-To: sci.crypt,comp.security.misc,comp.security.unix,alt.security,comp.sys.sun.admin From: mab@research.att.com (Matt Blaze) Subject: CFS 1.1.2 Unix encrypting file system source code available (free) Reply-To: mab@research.att.com Date: Tue, 27 Sep 1994 23:46:37 GMT I've received a larger-than-usual number of queries for info about CFS over the last couple of weeks, so it seems like a good time to post this. Sorry to those who've see this before. -matt ==================================================================== Source code for version 1.1 of CFS, the Cryptographic File System, is now available upon request for research and experimental use in the US and Canada. CFS pushes encryption services into the Unix(tm) file system. It supports secure storage at the system level through a standard Unix file system interface to encrypted files. Users associate a cryptographic key with the directories they wish to protect. Files in these directories (as well as their pathname components) are transparently encrypted and decrypted with the specified key without further user intervention; cleartext is never stored on a disk or sent to a remote file server. CFS employs a novel combination of DES stream and codebook cipher modes to provide high security with good performance on a modern workstation. CFS can use any available file system for its underlying storage without modification, including remote file servers such as NFS. System management functions, such as file backup, work in a normal manner and without knowledge of the key. CFS runs under SunOS and several other BSD-derived systems with NFS. It is implemented entirely at user level, as a local NFS server running on the client machine's "loopback" interface. It consists of about 5000 lines of code and supporting documentation. You must have "root" access to install CFS. CFS was first mentioned at the work-in-progress session at the Winter '93 USENIX Conference and was more fully detailed in: Matt Blaze, "A Cryptographic File System for Unix", Proc. 1st ACM Conference on Computer and Communications Security, Fairfax, VA, November 1993. (PostScript available by anonymous ftp from research.att.com in the file dist/mab/cfs.ps.) and in Matt Blaze, "Key Management in an Encrypting File System", Proc. Summer '94 USENIX Tech. Conference, Boston, MA, June 1994. (PostScript available by anonymous ftp from research.att.com in the file dist/mab/cfskey.ps.) The version being released differs from the version described in the paper in a few ways: * The encryption scheme has been strengthened, and now provides approximately the nominal strength of 3-DES with the online latency of only single-DES. * Support for the smartcard-based key management system is not included. * A few of the tools are not included * The performance has been improved. * The security of the system against certain non-cryptanalytic attacks has been improved somewhat. New features in CFS 1.1 include: * User-contributed ports to a number of additional platforms. * Better hooks for adding new ciphers. * 3-DES encryption option. CFS is being distributed as a research prototype; it is COMPLETELY UNSUPPORTED software. No warranty of any kind is provided. We will not be responsible if the system deletes all your files and emails the cleartext directly to the NSA or your mother. Also, we do not have the resources to port the software to other platforms, although you are welcome to do this yourself. The software was developed under SunOS and BSDI, and there are also unsupported user-contributed ports available for AIX, HP/UX, Irix, Linux, Solaris and Ultrix. We really can't promise to provide any technical support at all, beyond the source code itself. We also maintain a mailing list for CFS users and developers; subscription information is included with the source code. Because of export restrictions on cryptographic software, we are only able to make the software available within the US and Canada to US and Canadian citizens and permanent residents. Unfortunately, we cannot make it available for general anonymous ftp or other uncontrolled access, nor can we allow others to do so. Sorry. Legal stuff from the README file: * Copyright (c) 1992, 1993, 1994 by AT&T. * Permission to use, copy, and modify this software without fee * is hereby granted, provided that this entire notice is included in * all copies of any software which is or includes a copy or * modification of this software and in all copies of the supporting * documentation for such software. * * This software is subject to United States export controls. You may * not export it, in whole or in part, or cause or allow such export, * through act or omission, without prior authorization from the United * States government and written permission from AT&T. In particular, * you may not make any part of this software available for general or * unrestricted distribution to others, nor may you disclose this software * to persons other than citizens and permanent residents of the United * States and Canada. * * THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED * WARRANTY. IN PARTICULAR, NEITHER THE AUTHORS NOR AT&T MAKE ANY * REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY * OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE. If you would like a copy of the CFS source code, please send email to: cfs@research.att.com DO NOT REPLY DIRECTLY TO THIS MESSAGE. You must include a statement that you are in the US or Canada, are a citizen or legal permanent resident of the US or Canada, and have read and understand the license conditions stated above. Also include an email address in a US or Canada-registered domain. The code will be sent to you via email in a uuencoded compressed tarfile. ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************