> On Sun, May 31, 1998 at 08:55:01PM +0200, Riccardo Facchetti wrote:
> > Yes. I know. This is the bigger point against my idea. How to associate in
> > a secure way a running kernel with its image file, and in any kind of boot
> > setup. Having an answer to this question will resolve the bloating
> > problem.
>
> Depends. If you want to be sure to have access to
> ..config/System.map/whatever even if at boot time it was sent to you in
> morse code through supernovaes explosions, you can't do anything but
> keeping the data in memory.
You are right, but I think that here is time for assumptions.
I assume the boot image of the running kernel is available. I assume that
the named boot image contains the data related to it and I assume that I
can read it from the boot image file. Any other setup is possible, but I
think it is not a big percentage of actually linux boxes installed.
Let's see why:
1) root filesystem is local: box booted with LILO or equivalent.
Here the boot image is available as a file.
2) boot from floppy disk with local filesystem.
The boot image is /dev/fd0, readable. You can extract the data
from /dev/fd0.
If this is a rescue disk, the real problem is not having or not the
System.map and .config available, but to rescue your crashed system.
If you are installing a distribution, you can load the data permanently
in RAM (if you need it) until you reboot the system. After that you are
in 1).
If your filesystem is remote, you want to extract the floppy disk after
boot. Your remote root filesystem can contain the boot image (you copy
it in a known location and you are in 1).
3) If you boot from network, you have a remote filesystem, but you can
copy your boot image somewhere in the remote root filesystem and you
are again in 1).
Is there something I have not considered ?
> If you only want to confirm that the kernel image (to which has been
> appended all the information you want) you see lying there on the disk
> in the booted one, simply add a MD5 checksum[1] in the file loaded
> (not computed) at boot time and accessible through a system call or
> /proc.
>
> OG.
>
> [1] write a special zone in the file with 16 zeroes, compute the hash,
> write the result in the zone.
Good idea to check boot image and concatenated data coherency.
Ciao,
Riccardo.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu