Path: utzoo!utgpu!watmath!att!rutgers!ucsd!usc!samsung!aplcen!haven!umd5!feldman
From: feldman@umd5.umd.edu (Mark Feldman)
Newsgroups: comp.sys.next
Subject: Re: kernel corruption on 330Mb hd???
Message-ID: <5631@umd5.umd.edu>
Date: 16 Nov 89 20:34:08 GMT
References: <17504@kuhub.cc.ukans.edu> <5604@umd5.umd.edu> <12811@polya.Stanford.EDU> <12837@polya.Stanford.EDU>
Reply-To: feldman@umd5.umd.edu (Mark Feldman)
Organization: University of Maryland, College Park
Lines: 57

In article <12837@polya.Stanford.EDU> ali@Polya.Stanford.EDU (Ali T. Ozer) 
writes:
...
>The bug has been discovered and there is a workaround, in fact, an incredibly
>simple one.  Launch a Shell, become root, and remove the executable bit on 
>your kernel:
>
>	su
>	[type password]
>	chmod a-x /sdmach

Ok, I read it, I did it, but I'm not very happy about the implications.

>The problem occurs if you try to launch an executable in the Mach preload
>format; depending on how the pages our laid out in the file, a part of the
>file might become corrupted if paging occurs after the file is "launched."

The files /sdmach and /odmach (which are the same file) are owned by root
and their permissions are 555 -- readable and executable by all, writable by
none.  How is it that the file can be written to when it is executed by a
user other than root?

>Mach preload executables are meant to be bootable images and are not meant
>to be executed by the demand-paged system; thus your system will not lose
>any functionality when you remove the executable bit.  You will just be
>assuring that the kernel is not launched inadvertently (either from the
>Shell or with a double-click), which is probably what caused the
>problem in all cases.  

The fact that it is possible to write to a file when you don't have
permission is very bad.  Very, very bad.  And why would the system ever try
to page back to a program file?  Me thought that that is what a swap file
was for.

>There are only two preload format files in the system, the kernel and the boot 
>file.  The boot file has been shipped without the executable bit so it's fine.

Not fine.  Getting an error back when trying to execute one of these files
would be fine.  Getting a core dump would be ok.  Having the original, write
protected file corrupted is not.

>Thanks to Alan Marcum and Avie for the explanation and workaround.
>
>Ali
>

Ali, if the fix will keep my kernels from being corrupted, thanks!  If it's
one thing that I can't stand, it's a corrupted kernel.  But what am I
missing?

  Mark


p.s.

If someone has a NeXT and does not have USENET access, how will they find
out about the fix?