[TALK] Proving fundamental Unix guarantees

Gary Schmidt gary.schmidt at oz.quest.com
Mon Jun 30 16:36:18 EST 2003


>
> Based on the replies I have received, maybe I should have included
> more information.
Ta.

> We have bumped into a problem where a warm reboot (eg "shutdown -r")
> gives different behaviour to a cold reboot (eg "shutdown -h"/boot).
> According to the vendor, the only difference is that in the latter
> case physical RAM will be initialised, whereas in the former case it
> retains the previous values.  I have suggested that this appears to
> indicate that the kernel is using memory without initialising it -
> which is a bug in the kernel.  The vendor has suggested that the
> kernel passes memory to the application without initialising it and
> therefore it is a bug in the application.
That's a strange and nasty one.  Keep at them, they may start blaming the phases of the moon too!

> Whilst I agree that there may be bugs in the application, having a
> kernel pass uninitialised memory to a userland process is a major
> security hole.
Yes, it sure is.  Not to mention sectors on disk that used to belong to files.

> (Want another process to be given a copy of your
> su/pgp/ssh processes memory image?)  I have confirmed that as far as I
> can determine (and as expected), all memory is initialised before
> being passed to the application.
> 
> Definitely the C standards require uninitialised static variables
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Are a special case.  Again, there is no reqiurement on the behaviour of unitialised _global_ variables.  The difference is subtle but crucial.

> (which are normally stored in BSS) to be initialised as if they were
> assigned zero (which is zero on most systems) - though the mechanism
> isn't specified.  I was hoping that some of the POSIX or SVID
> standards might say some words on the the kernel/userland interface.

OS and version and hardware and product which is causing the problem might help, too.

	Cheers,
		Gary	B-)



More information about the Talk mailing list