Files
2024-02-19 00:25:02 -05:00

673 lines
25 KiB
Plaintext

From: Digestifier <Linux-Activists-Request@news-digests.mit.edu>
To: Linux-Activists@news-digests.mit.edu
Reply-To: Linux-Activists@news-digests.mit.edu
Date: Sat, 22 Feb 92 11:15:08 EST
Subject: Linux-Activists Digest #61
Linux-Activists Digest #61, Volume #1 Sat, 22 Feb 92 11:15:08 EST
Contents:
Re: Why can't /dev/kmem be world-readable? [was Re: More questions about Linux :-)] (Charles Hedrick)
Re: Current status of LINUX (Charles Hedrick)
COM3/COM4 problems: almost there! (nmurrayr@cc.curtin.edu.au)
Re: COM3/COM4 problems: almost there! (Jay Hofacker)
Banner (Dylan Smith)
Question... (Lynn Scott Wood)
Easy video mode changes, nonstandard disk support, and v86 mode (Drew Eckhardt)
GCC (anspaugh@memstvx1.memst.edu)
Mtools? (Boston)
Re: Vixie cron fix (Thomas David Rivers)
Re: Easy video mode changes, nonstandard disk support, and v86 mode (Curtis Yarvin)
Problems making backups (sweh)
Re: floating point (Charles Hedrick)
Re: Why cant /dev/kmem be world-readable? [was Re: More questions about Linux :-)] (Rick Kelly)
Patches to have reboot and /dev/kmem working (D.Bolla)
Re: Easy video mode changes, nonstandard disk support, and v86 mode (D.Bolla)
----------------------------------------------------------------------------
From: hedrick@dumas.rutgers.edu (Charles Hedrick)
Subject: Re: Why can't /dev/kmem be world-readable? [was Re: More questions about Linux :-)]
Date: 20 Feb 92 06:09:35 GMT
>This is probably an ignorant question, but why does giving ordinary
>users READ (certainly not WRITE) access to /dev/kmem compromise system
>security?
Because they could then run programs that look through the kernel
data structures and see what other users are doing. E.g. there's
a program that will display everything being typed on all the
terminals. Instant eavesdropping.
------------------------------
From: hedrick@dumas.rutgers.edu (Charles Hedrick)
Subject: Re: Current status of LINUX
Date: 20 Feb 92 06:19:40 GMT
>Would somebody please tell me what is the current status of linux?
>How complete it is? What is still missing from linux?
>Why I should not start the use of linux for serious programming, text
>typesettings and so on?
The kernel and basic utilities are there. "Traditional" Unix
functionality, i.e. roughly version 7 or System V release 2, is there.
Major new features missing are networking and a window system.
Floating point is in serious disarray, but should be fixed shortly.
For C programming that doesn't use floating point, it's fine (unless
you need a debugger -- that is also reported to be coming out
shortly). Note that there are no man pages for the system calls or
libraries. You'll need documentation for some version of Unix that is
close to POSIX, and you'll probably have to consult the sources to
libc now and then for details.
For text processing, you've got a problem: at least on tsx-11.mit.edu
and banjo.concert.net, none of the major formatters is available yet.
All the necessary facilities are there. Porting groff or TeX, should
be fairly straightforward (or do they require floating point?), but it
doesn't look like it's done yet.
In my view there are enough loose ends that it's going to be a couple
of months before it makes sense for large numbers of people to use it
as their primary system, though I'm doing so now. (The major
applications I need are communications and a Bible reference program.
For communications I have kermit and KA9Q, for the Bible reference
program I have Bibleref.) A short wait will let the people who are
working on installation instructions have a bit more time.
On the other hand, it's in fine shape for people who want to start
porting software to it, and there's a merry band doing just that.
------------------------------
From: nmurrayr@cc.curtin.edu.au
Subject: COM3/COM4 problems: almost there!
Date: 22 Feb 92 02:03:16 GMT
I modified the serial routines so that they'd work with com3/com4 as well
as com1/com2 (at the cost of some extra time spent in the interrupt routine;
I'm not sure whether this is avoidable or not). The catch was that, once this
was done, only com3 (which is a SLIP link running to a 286 running ka9q) would
work -- yet if I disabled the code initialising com3, kermit would work fine
on com1 (a modem). As far as I remember, com2 worked (it's a mouse, and I think
I got the usual alphabet soup when I ran kermit on com2 and moved the mouse).
I don't have com4 installed.
Eventually I realised that the problem was caused by the brain-damaged ISA
interrupt system: presumably the driver on the com3 board which drives the IRQ
line has better drive capabilities than the one on the com1 board, so it just
took over IRQ4. I suppose I should have realised this earlier, and it wasn't
until I discovered that the port initialisaton code was enabling OUT2 on the
8250 (which enables the IRQ line driver) that the penny dropped.
It does seem, then, that you can't have programs which use both com1 and
com3 (or both com2 and com4) running at the same time -- but that doesn't mean
we can't use these programs at all. All we need to do is enable the interrupt
line on the appropriate port when we need it, and disable it when we've
finished.
Now, as I've said before, I don't know much about UNIX (although I seem
to be learning fast!). It seems that you can't directly access a hardware
port from a user program (I know; I've tried), but I assume it must be
possible somehow. Anyone know how?
To change the subject, here's my Silly Question of the Week: what's a pty?
.....Ron
--
***
Ron Murray
Internet: Murray_RJ@cc.curtin.edu.au
Are we having fun yet? -- Garfield
------------------------------
From: jayh@ms.uky.edu (Jay Hofacker)
Subject: Re: COM3/COM4 problems: almost there!
Date: Sat, 22 Feb 1992 02:42:26 GMT
nmurrayr@cc.curtin.edu.au writes:
> I modified the serial routines so that they'd work with com3/com4 as well
>as com1/com2 (at the cost of some extra time spent in the interrupt routine;
>I'm not sure whether this is avoidable or not). The catch was that, once this
>was done, only com3 (which is a SLIP link running to a 286 running ka9q) would
>work -- yet if I disabled the code initialising com3, kermit would work fine
>on com1 (a modem). As far as I remember, com2 worked (it's a mouse, and I think
>I got the usual alphabet soup when I ran kermit on com2 and moved the mouse).
>I don't have com4 installed.
> Eventually I realised that the problem was caused by the brain-damaged ISA
>interrupt system: presumably the driver on the com3 board which drives the IRQ
>line has better drive capabilities than the one on the com1 board, so it just
>took over IRQ4. I suppose I should have realised this earlier, and it wasn't
>until I discovered that the port initialisaton code was enabling OUT2 on the
>8250 (which enables the IRQ line driver) that the penny dropped.
> It does seem, then, that you can't have programs which use both com1 and
>com3 (or both com2 and com4) running at the same time -- but that doesn't mean
>we can't use these programs at all. All we need to do is enable the interrupt
>line on the appropriate port when we need it, and disable it when we've
>finished.
> Now, as I've said before, I don't know much about UNIX (although I seem
>to be learning fast!). It seems that you can't directly access a hardware
>port from a user program (I know; I've tried), but I assume it must be
>possible somehow. Anyone know how?
You can use two com ports at the same time on the same IRQ if they are both
in the same ISA slot, and you have a smart enough interupt service routine.
If both COM1 and COM3 are on IRQ4, then when you service an interupt for IRQ4
you have to check both COM1 and COM3 for received characters.
--
Jay Hofacker, sysop of the Audio/Visual Exchange, (606)254-1751 3/12/24 MNP 5
Email: jayh@ms.uky.edu --- "Hailing frequencies closed sir."
------------------------------
From: d_smith@csd.brispoly.ac.uk (Dylan Smith)
Subject: Banner
Date: 21 Feb 92 22:35:26 GMT
For those interested, for a little effort I've ported a banner program I
found in alt.sources, and it makes a good replacement for the one you
usually find in /usr/games on most unices, and as Linux dosen't have a
banner I thought "why not?"
I've uploaded it to /incoming at tsx-11.mit.edu, and it's banner.Z, a binary
(rather than the sources:they don't compile first time, but if you yell alot
at me I'll put them on tsx as well!)
--
Email : JANET d_smith@brispoly.csd | Everywhere else d_smith@csd.brispoly.ac.uk
FidoNet Address 2:252/204 | Data (v22/v22bis) phone 0491 875104
------------------------------
From: lwood@landau.ucdavis.edu (Lynn Scott Wood)
Subject: Question...
Date: 21 Feb 92 07:08:36 GMT
At the risk of being terribly disappointed, I ask this question:
I finally got linux 0.12 running from the floppies, but when I try
fdisk all I get is
/dev/hd4: 83206 block active 16-bit DOS (>=32M)
Does this mean that linux cannot recognize my hard drive? I'm using a
Packard-Bell Packmate 386X (386sx), which has an IDE interface built-into
the motherboard.
I'm not the best on hard drives - can I install a separate HD controller
and hard drive and use that?
I'm going to be really upset if all I can do is run linux off a floppy... :v)
-Lynn Wood
lwood@landau.ucdavis.edu
------------------------------
From: drew@hazelrah.Colorado.EDU (Drew Eckhardt)
Subject: Easy video mode changes, nonstandard disk support, and v86 mode
Date: 22 Feb 92 02:15:26 GMT
We want X11 up on Linux. Since not everybody has an ATI or Tseng chipset, we
also want to support the other cards out there - Trident 8800 / 8900,
Genoa, etc.
Now, the only real differences between these chips is in setup (mode
selection), and bank switching (to accomodate the 128K we have for video
buffer and 1M of modern SVGA cards). Setup is the difficult part, with over
20 registers that need to be set for each mode,
but this is easily accomplished by BIOS.
The problem is that we don't have BIOS in protected mode. Or do we?
The i386 gives us a nifty little feature for running real mode programs
as virtual 80x86 tasks. Unfortunately, these tasks must reside
at absolute address 0. Our current mm code requires that all processes
share the same page tables - meaning only one can live at
absolute address 0. However, if all we want is one (the BIOS routines ) this
is not a problem.
Specifically what needs to be done :
1. An interrupt vector table, as well as area for BIOS data should exist
at 0x00000 - ~600h bytes in length, 0x1000 bytes to maintain
4K alignment of page tables. This means that the
page directory and tables must move - change CRT0 - but not a real problem.
2. The general protection violation handler must check the vm flag, and
emualte sensitive instructions (IE int, cli, sti)
3. A task gate be created for the new task.
4. An interface between 32 bit protected and VM halves must be created.
5. We should probably approximate the system timer, updating every 1/5
ticks.
What this allows us to do :
Provide a simple, portable, flexible means for handling od-ball hardware,
especially graphics card initialization.
Also note that this would provide a quick and dirty way for interfacing
non-WD1003 compatable disk drives, where another driver does not
exist.
Note that the IO permissions can be set to protect HD, FD, etc access
(IOPL is ignored by VM tasks)
Other ideas :
A syscall, to handle bank switching? From personal experience, I'd say
that it is easier to recompile the Linux kernel than to rebuild the X11R5
server.
From a performance standpoint, bankswitching should be handled in
the X11R5 server via inline assembler. This works if we support all
SVGA boards.
From a flexibility standpoint, ease of modification, there should also
be a syscall, which can be patched to support every board, called if there
is no server code specific to that SVGA.
A report graphics hardware syscall should also be supported, to allow the
stock X server to run as distributed on any hardware.
Any comments? Takers?
------------------------------
From: anspaugh@memstvx1.memst.edu
Subject: GCC
Date: 21 Feb 92 23:06:25 -0600
What are all the libraries and proper procedures I need to set up GCC???
Has anyone been able to make curses operate properly???
------------------------------
From: bboston@engws8.ic.sunysb.edu (Boston)
Subject: Mtools?
Date: 22 Feb 92 04:12:00 GMT
I am having some problems with using Linux, mainly I can't do anything! I have
finally gotten it installed on my HD, but how do I get files there? I believe I
need Mtools, but how can I compile Mtools if I can't get GCC on the HD because
I can't use mtools to read this disk! Does anyone out there have an image of
mtools? Thanks
bboston@engws8.ic.sunysb.edu
------------------------------
From: rivers@ponds.uucp (Thomas David Rivers)
Subject: Re: Vixie cron fix
Date: 21 Feb 92 12:33:55 GMT
In conversations with Linus; the cause of the Vixie-Cron processes has
been determined.
Linux doesn't "do the SysV thing" when SIGCHLD is set to sig_ign. In
this case; when a child dies, it's supposed to be purged from the
process table - at least according to the Sys V man pages I have (see
signal()).
Anyway, Linus said he thought it was a straight-forward fix, and should
be in version 0.13.
- Dave Rivers -
------------------------------
From: cgy@cs.brown.edu (Curtis Yarvin)
Subject: Re: Easy video mode changes, nonstandard disk support, and v86 mode
Date: Sat, 22 Feb 1992 07:17:09 GMT
In article <1992Feb22.021526.225@colorado.edu> drew@hazelrah.Colorado.EDU (Drew Eckhardt) writes:
>We want X11 up on Linux. Since not everybody has an ATI or Tseng chipset, we
>also want to support the other cards out there - Trident 8800 / 8900,
>Genoa, etc.
What's wrong with device drivers? Ioctls for bank switching and so forth,
and maybe a mappable frame buffer, and porting X should be clean enough.
c
------------------------------
From: sweh@spuddy.uucp (sweh)
Subject: Problems making backups
Date: 20 Feb 92 21:07:52 GMT
Hi,
I'm new to Linux having caught a reference to it somewhere (forget where)
and have downloaded the 0.12 boot/root plus a few other goodies, and I must
say I am very impressed - except for no UK keyboard.
I repartioned my hard disk to give a 15Mb root and 5Mb swap to go with my 4Mb
RAM and it works AOK.
However, I have hit one problem....
tar cvfM /dev/at0 .
from the root directory freezes up at roughly /bin/update
If I try and kill the process from another screen then the kill hangs as well.
Yet, tar cvf /tmp/backup ./"everything except tmp"
works, and tar cvfM /dev/at0 /tmp/backup also works.
It seems to be the combination of reading from hard disk and writing to floppy
that fails.
The boot/root/everything else all came from tsx-11 within the past month.
Any ideas? Thanks
--
Stephen Harris
sweh@spuddy.uucp ...!uknet!axion!spuddy!sweh
* Meeeeow ! Call Spud the Cat on > +44 203 638780 < for free Usenet access *
------------------------------
From: hedrick@athos.rutgers.edu (Charles Hedrick)
Subject: Re: floating point
Date: 22 Feb 92 04:26:32 GMT
Assuming that the new gcc and libraries really do as advertised, I
thank you most heartily for doing them. However as a long term
direction, I'd like to see things move back in the direction Linus
originally started, i.e. of putting floating point emulation in the
kernel rather than a library.
Our experience on Sun 3s was that as long as there have to be separate
libraries for hardware and software f.p., most binaries get built with
the software floating point. Most people don't want to have to keep
two binaries around for all software, and the default for most
compilers is the "safe" one -- software f.p. With the Sparc
architecture, Sun went to assuming that everybody had hardware
floating point. For those who didn't, the kernel would do emulation.
This meant that there was only one library, and all software was built
assuming hardware floating point. Thus the people who choose to buy
hardware floating point get optimal performance, and those without it
pay the penalty. With the Sun 3 strategy, things were effectively
optimized for the people who hadn't bothered to get floating point
hardware, which seems backwards.
------------------------------
Subject: Re: Why cant /dev/kmem be world-readable? [was Re: More questions about Linux :-)]
From: rmk@rmkhome.UUCP (Rick Kelly)
Date: Sat, 22 Feb 1992 14:01:43 GMT
Reply-To: rmk@rmkhome.UUCP (Rick Kelly)
In article <Feb.20.01.09.34.1992.3696@dumas.rutgers.edu> hedrick@dumas.rutgers.edu (Charles Hedrick) writes:
>>This is probably an ignorant question, but why does giving ordinary
>>users READ (certainly not WRITE) access to /dev/kmem compromise system
>>security?
>Because they could then run programs that look through the kernel
>data structures and see what other users are doing. E.g. there's
>a program that will display everything being typed on all the
>terminals. Instant eavesdropping.
And it's a great way to find passwords.
--
Rick Kelly rmk@rmkhome.UUCP unixland!rmkhome!rmk rmk@frog.UUCP
------------------------------
From: db1@ukc.ac.uk (D.Bolla)
Subject: Patches to have reboot and /dev/kmem working
Date: 22 Feb 92 13:50:56 GMT
Hello
This time I have some small solutions :-)
The first one is the implentation of the reboot syscall.
The syscall just does a reboot after having checked that you are root.
The old method does not work anymore ( CTRL-ALT-DEL )
The second is an implementation of the /dev/kmem. Most of the code is
done by linux. I just added FEW lines in the right place ( I hope ).
The point is that with this /unix and nlist(3) it is possible to get
all information we need from the kernel WITHOUT having to add code to the
kernel.
It seems to me that people who complain about "normal users cannot read
/dev/kmem" and "A library to read kernel data is not nice" don't have a
clear idea about what /dev/kmem is used for.
When you look in /dev/kmem you look for VERY special information about
the system. I am not sayng that normal user should be denied ps :-)
but if you think, normal users use ps just to see what others are doing
( The same thing for w )
Anyway.... under Sun there are three programs that "look" into /dev/kmem
ps, w, pstats. The amount of information you can get out of them is very
big. The point that I am tryng to make here is:
To obtain the same amount of information from syscalls you need a
GREAT number of variations and parameters. Is this worth the work ?
( Considering the small amount of programs that need that information )
Again.....
Negative points of kernel implementation.
1) Extra (Unnecessary) code in the kernel -> Kernel bigger.
2) Possible introduction of ERRORS -> Kernel panic.
3) Increased number of syscall and paramentrs -> Complexity
4) Problems on returning lists of data in user space
To me point 2 is already enough NOT to use this method. If you can live
with possible kernel panics.......
Positive points of a library implementation.
1) NO extra code in the kernel. -> Save memory
2) Impossibility to add ERRORS to the kernel code. -> NO panic
3) Easy to update, modify even by average user.
4) No problems in allcating memory for the result.
What it is important is to DEFINE what information we want to
extract from /dev/kmem and who can use them. After that is defined it
is possible to discuss about implementaion.
And now to the code :-)
=================================================================
I decided to put the actual routine that does reboot into
kernel/sys.c Probably your sys.c may be different....
522a523,533
> /* This function reboots the system if the current UID is root
> * No sync is performed. The optional flag is not used yet
> * The called routine is in kernel/chr_drv/keyboard.S
> */
> int sys_reboot ( int flag )
> {
> if (!suser())
> return (-EPERM);
> __asm__("call _hard_reset;" );
> return (0);
> }
The next step is to add the syscall code in the file
include/unistd.h
148a149
> #define __NR_reboot 87
And then add the syscall address in the file
include/linux/sys.h
91a92
> extern int sys_reboot();
108c109
< sys_lstat, sys_readlink, sys_uselib };
---
> sys_lstat, sys_readlink, sys_uselib ,sys_reboot };
The last bit is to modify the keyboard.S file
kernel/chr_drv/keyboard.S
This file is different from yours so.... don't just apply the diff
Understand what it does and do it by hand.
25a26
> .globl _hard_reset
203c204
< jne reboot
---
> jne 1f /* CTRL-ALT-DEL */
659c660
< reboot:
---
> _hard_reset:
661,662c662,663
< movw $0x1234,0x472 /* don't do memory check */
< movb $0xfc,%al /* pulse reset and A20 low */
---
> movw $0x1234,0x472 /* don't do memory check */
> movb $0xfc,%al /* pulse reset and A20 low */
At this point recompile the kernel and all should go together.
Unfortunately the work is NOT finished. You have to add the syscall to
libc.a To do this you need the source for the library. Usually in
/usr/src/lib. Go into the unistd directory and create the file
reboot.c with the following content.
/* This function will reboot the syestem
*/
#define __LIBRARY__
#include <unistd.h>
_syscall1(int,reboot,int,param)
And then modify the Makefile as follow.
At the end of OBJ=.... list add reboot.o and do a make dep
Before making the new libary you have to change the standard unistd.h library
file to point to the unistd.h file in the linux directory
cd /usr/include
rm unistd.h
ln -s /usr/src/linux/include/unistd.h unistd.h
At this point you can make the new libc.a
Then you can experiment with the new syscall.
Eg:
#include <stdio.h>
#include <errno.h>
main ()
{
if ( reboot (1) ==(-EPERM) )
printf ("Not superuser \n");
exit (-1);
}
=============================================================
The second part is a patch that gives you access to the kernel memory
in particular kernel DATA memory.
The following diff applies to the file fs/char_dev.c and in particular
to the function rw_kmem .
52,54c52,67
< {
< return -EIO;
< }
---
> {
> int i = *pos; /* Current position where to read */
>
> /* i can go from 0 to LOW_MEM (See include/linux/mm.h */
> /* I am not shure about it but it doesn't mem fault :-) */
> while ( (count-- > 0) && (i <LOW_MEM) )
> {
> if (rw==READ) put_fs_byte( *(char *)i ,buf++);
> else return (-EIO);
> i++;
> }
>
> i -= *pos; /* Count how many read or write */
> *pos += i; /* Update position */
> return (i); /* Return number read */
> }
NOTE: The LOW_MEM value may not be the most appropriate. Linus please
confirm if it is the correct one.
Damiano
------------------------------
From: db1@ukc.ac.uk (D.Bolla)
Subject: Re: Easy video mode changes, nonstandard disk support, and v86 mode
Date: 22 Feb 92 14:18:00 GMT
Reply-To: db1@ukc.ac.uk (D.Bolla)
In article <1992Feb22.071709.14782@cs.brown.edu> cgy@cs.brown.edu (Curtis Yarvin) writes:
>In article <1992Feb22.021526.225@colorado.edu> drew@hazelrah.Colorado.EDU (Drew Eckhardt) writes:
>>We want X11 up on Linux. Since not everybody has an ATI or Tseng chipset, we
>>also want to support the other cards out there - Trident 8800 / 8900,
>>Genoa, etc.
>
>What's wrong with device drivers? Ioctls for bank switching and so forth,
>and maybe a mappable frame buffer, and porting X should be clean enough.
^^^^^^^^^^^^^^^^^^^^^
YES
Agreed !
I have a NON standard VGA card. It seems that I should be interested in
using the BIOS, right ?
NO.
This is UNIX. Let's leave DOS OUT !
This doesn't mean that we loose the card. It means that we use UNIX
tools to achieve the same result.
Eg: What about starting all the time using VGA and when the system is up
and running using ioctl to select various modes ?
It IS possible to avoid BIOS. !
Damiano
------------------------------
** 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-Activists-Request@NEWS-DIGESTS.MIT.EDU
You can send mail to the entire list (and alt.os.linux) via:
Internet: Linux-Activists@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
tupac-amaru.informatik.rwth-aachen.de pub/msdos/replace
The current version of Linux is 0.12, released on Jan 14, 1992
End of Linux-Activists Digest
******************************