Files
oldlinux-files/ftp-archives/tsx-11.mit.edu/1996-10-07/mail-archive/linux-devel/Volume2/digest236
2024-02-19 00:24:15 -05:00

495 lines
20 KiB
Plaintext

From: Digestifier <Linux-Development-Request@senator-bedfellow.mit.edu>
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 <hamish@zot.apana.org.au> 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 <CwoFHF.Hxs@undergrad.math.uwaterloo.ca>,
<scheidel@gate.net> 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 <shrug>),
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
******************************