Ron Heiby (The Moderator) <unix-request@cbosgd.UUCP> (03/14/85)
Unix Technical Digest Thu, 14 Feb 85 Volume 1 : Issue 17
Today's Topics:
Plexus P/40 System III Release 1.2 'C' compiler/library bug (2 msgs)
When does ( alarm(1) == alarm(INFINITY) ) ? (5 msgs)
Wyse 50 (Security Aspects)
----------------------------------------------------------------------
Date: 12 Mar 85 23:51:38 GMT
From: ignatz@aicchi.UUCP (Ihnat)
Subject: Plexus P/40 System III Release 1.2 'C' compiler/library bug
Hello, folks. Just a bit of a problem we encountered, that I thought
other Plexus owners might like to look at. We're running the Plexus
System III Release 1.2 that was just released around 2-3 months ago.
A fellow here at AiC is learning about Unix(Tm) and 'C', so I thought
to give him the old "What does the following program do?" problem:
#include <stdio.h>
main()
{
char buff[64];
setbuf(stdout,buff);
fprintf(stdout,"This is a message\n");
fprintf(stderr,"And this is an error\n");
}
He dutifully compiled it with 'cc -o dork dork.c', and executed
the resultant file. Much to my surprise, this resulted in:
And this is an error
This~^R^G^Z^A~x^Rage
(Control characters translated to protect the innocent).
Some boring poking with adb resulted in the not surprising
fact that the stack and data were crawling down each other's
throats; the only surprising thing was that this happened at all
on such a small, simple program. Has anyone else found this?
If not, maybe you could try it so, if it's not in the known
problem list (I've not found it yet), I can let them know that
others have encountered it. Also, it's then something to look
out for.
--
Dave Ihnat
Analysts International Corporation
(312) 882-4673
ihnp4!aicchi!ignatz
------------------------------
Date: 13 Mar 85 06:30:15 GMT
From: ksbszabo@wateng.UUCP (Kevin Szabo)
Subject: Plexus P/40 System III Release 1.2 'C' compiler/library bug
Setbuf expects the buffer to be BUFSIZ big. STDIO has no
way of finding out how big your buffer really is.
Reading the man page for SETBUF should clarify this.
Peeking at the source ain't bad either.
--
Kevin Szabo watmath!wateng!ksbszabo (U of Waterloo VLSI Group, Waterloo Ont.)
------------------------------
Date: 8 Mar 85 15:37:13 GMT
From: andrews@calgary.UUCP (Keith Andrews)
Subject: When does ( alarm(1) == alarm(INFINITY) ) ?
> I wrote the following fudge routine to handle a similar problem
> when using 4.1 BSD. The 4.2 signal stuff allows a cleaner (though
> less efficient) solution. It only works on the VAX as written, though
> adaptation to other machines would probably be possible.
>
> static char pause_routine[5]; /* Pause system call or nop's */
> /* Set up a routine to do a "pause" system call. */
> jk_set_up_pause()
> { register char *p;
[etc.]
Although this solution to the problem may be sound, this method of implementing
it is, er... dumb (to say the least). The following implementation is much
easier to understand, simpler and (Oh wow!) portable:
int (*foo)();
int pause();
...
{
...
/* Point at the pause() call */
foo = pause;
/* Set up alarm */
alarm(1);
/* Actually do pause (well, maybe) */
(*foo)();
/* Proceed merrily along */
}
int null()
{} /* Do nothing function */
alarm_signal_handler()
{
foo = null;
}
Keith Andrews
U of Calgary, Dept. of CS
------------------------------
Date: 8 Mar 85 22:15:38 GMT
From: radford@calgary.UUCP (Radford Neal)
Subject: When does ( alarm(1) == alarm(INFINITY) ) ?
> [Insert Keith's message here]
>
> Keith Andrews
> U of Calgary, Dept. of CS
Unfortunately, this implementation of the solution DOES NOT WORK!
One must make sure that no race occurs if the interrupt occurs at ANY
time, right up to the instruction which transfers control to the
kernel. In the above, it is still possible for the pause procedure to
be called before the interrupt but for it to occur before the chmk
instruction *within* the the pause procedure is executed. Since a VAX
procedure call takes quite a while, this is not all that unlikely. It
is also possible that the statement (*foo)(); itself will be compiled
into several instructions (it definitely will be on a 68000).
There may be a marginally cleaner way of doing this using "indirect
system calls", which exist on PDP11 Unices (at least). I see no way
of doing it in a machine-independent manner without the appropriate
kernel extensions such as 4.2 has. The code-modification technique
might still be useful on a 4.2 system if interrupts occur lots of
times, making the appropriate sighold (or whatever, I haven't read the
manual recently) calls too time-consuming.
Radford Neal
The University of Calgary
------------------------------
Date: 10 Mar 85 23:52:18 GMT
From: wapd@houxj.UUCP (Bill Dietrich)
Subject: When does ( alarm(1) == alarm(INFINITY) ) ?
I tried the program sent in a previous article on System V release 2
on a VAX-11/780, a 3B-20S and a 3B-5. No hang on any of them.
The program settled down to a pattern like '+-----+---+----+----'
after about 10 characters, on each machine.
Bill Dietrich
ihnp4!houxj!wapd
------------------------------
Date: 12 Mar 85 18:52:28 GMT
From: ptw@encore.UUCP (P. Tucker Withington)
Subject: When does ( alarm(1) == alarm(INFINITY) ) ?
It seems to me that the ill-defined functionality of alarm, signal, and pause
is just a plain, old, *bug* that should be addressed by AT&T and/or the Unix
standards committee rather than hack-fixed. (Maybe they already did?)
My proposal (2 cent royalty):
The *kernel* should maintain a per-process "wakeup waiting" flag that is
cleared by signal, set when a signal is caught in user mode, and causes pause
to return immediately (as if interrupted) if it is set when a pause is invoked.
I believe this would both eliminate the race/vulnerable condition and stay
within the original intent of the semantics of signals and pause. (To the
extent that read, write, and wait have similar semantics w.r.t. signals, they
should also use the flag.)
o.o --tucker
~
------------------------------
Date: 12 Mar 85 19:25:56 GMT
From: ptw@encore.UUCP (P. Tucker Withington)
Subject: When does ( alarm(1) == alarm(INFINITY) ) ?
As long as I'm opening myself up to flames...
It just occurred to me that with a simple change to the semantics of pause the
"wakeup waiting" flag could be considered to already be in the kernel:
As I read the manual (I didn't read the code) pause will only return when a
signal is "caught". If the semantics were that it would also return
(immediately) if there were no signal handlers active (since they revert when
caught), the race condition would also disappear. Pause could even return a
different error in this case, informing you that there is nothing to pause for
(in the spirit of ECHILD) if you really want to go whole hog.
o.o --tucker
~
(I know, I really should be using 4.2 and I do, but SysV ain't all *that* bad
either.)
------------------------------
Date: 7 Mar 85 20:58:11 GMT
From: jwp@sdchema.UUCP (John Pierce)
Subject: Wyse 50 (Security Aspects)
People using the Wyse 50 should note that it is yet another terminal that
accepts block-send instructions from the host, and there is no way for the
user to turn off that "feature". We did manage to get ROMs from Wyse that
disable it, however.
John Pierce, Chemistry, UC San Diego
{sdcsvax,decvax}!sdchema!jwp
jwp@ucsd
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / ihnp4!{wnuxa!heiby|wnuxb!netnews}
AT&T Information Systems, Inc.
Lisle, IL (CU-D21)