Xref: utzoo comp.lang.c:14325 comp.unix.wizards:12919 Path: utzoo!attcan!uunet!husc6!rutgers!ucsd!brian From: brian@ucsd.EDU (Brian Kantor) Newsgroups: comp.lang.c,comp.unix.wizards Subject: Re: Insecure hardware (was Re: gets(3) nonsense) Message-ID: <1282@ucsd.EDU> Date: 28 Nov 88 05:38:19 GMT References: <867@cernvax.UUCP> <645@quintus.UUCP> <339@igor.Rational.COM> <644@scotty.UUCP> <288@ispi.UUCP> <2330@cbnews.ATT.COM> <4869@bsu-cs.UUCP> Reply-To: brian@ucsd.edu (Brian Kantor) Organization: The Avant-Garde of the Now, Ltd. Lines: 30 In article <4869@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >However, it is rumored that there are machines that maintain a tag >value with each word. On such a machine, a return address on the stack >would be tagged as a 'code address'. Overwriting it with the data read >by gets() would remove the 'code address' tag and replace it with a >'character data' tag, preventing a return to that address. Such machines do exist; we have one of them here - a ancient beast known as a Burroughs 7800. Since the architecture of such a machine dates from the middle SIXTIES, one wonders why more such equipment isn't being made, especially in these days of cheap (well, not-as-cheap-as-two-years-ago) memory. The Burro uses a three-bit tag on each of its 48 data-bit words to signal whether a word is code, data, array descriptor, pointer, stack control word, etc. It also does array bounds checking in hardware as part of the index calculation, and allocates arrays in virtual space (segmented, if necessary) with a descriptor on the stack instead of the whole array on the stack, and has special stack control words so the firmware can cut the stack back on procedure exit, etc, etc, etc. Oh, and the program counter stack is separate from the data stack, so there is NOTHING you can do that will bugger the return addresses. Ah well, make something ahead of its time, and nobody remembers.... Brian Kantor UCSD Office of Academic Computing Academic Network Operations Group UCSD B-028, La Jolla, CA 92093 USA brian@ucsd.edu ucsd!brian BRIAN@UCSD