[PATCH] kexec/uImage: probe to identify a corrupted image

Simon Horman horms at verge.net.au
Thu Apr 25 09:26:47 EDT 2013


On Wed, Apr 24, 2013 at 10:50:43AM +0530, Suzuki K. Poulose wrote:
> On 04/17/2013 03:52 PM, Suzuki K. Poulose wrote:
> >From: Suzuki K. Poulose <suzuki at in.ibm.com>
> >
> >Teach uImage_probe_xxx() to return the information about
> >a corrupted image. This is required to prevent the loading
> >of a corrupted ramdisk, where we don't have strict checking
> >for the other formats, unlike the kernel. So, we should abort
> >the operation than causing a problem with the new kernel.
> >
> >Without this patch, a corrupted uImage ramdisk is treated as
> >a plain ramdisk where there is no format check involved.
> >
> ># kexec -l uImage --initrd romfs-initrd.corrupt
> >The data CRC does not match. Computed: 867e73f7 expected 8f097cc0
> ># echo $?
> >0
> ># kexec -e
> >Starting new kernel
> >Bye!
> >Reserving 55MB of memory at 70MB for crashkernel (System RAM: 256MB)
> >Using Xilinx Virtex440 machine description
> >Linux version 3.6.0-rc3 (root at suzukikp) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (GCC) ) #66 Tue Apr 16 06:36:56 UTC 2013
> >Found initrd at 0xcf5f8000:0xcfff8040
> >...
> >
> >NET: Registered protocol family 17
> >RAMDISK: Couldn't find valid RAM disk image starting at 0.
> >List of all partitions:
> >No filesystem could mount root, tried:  ext2 cramfs
> >Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
> >
> >
> >With this patch :
> >
> ># kexec -l uImage --initrd romfs-initrd.corrupt
> >uImage: The data CRC does not match. Computed: 867e73f7 expected 8f097cc0
> >uImage: Corrupted ramdisk file romfs-initrd
> >
> >With a corrupted kernel image(the behaviour remains the same) :
> ># kexec -l uImage.corrupt --initrd romfs-initrd
> >uImage: The data CRC does not match. Computed: 285787b7 expected e37f65ad
> >Cannot determine the file type of uImage.corrupt
> >
> >Signed-off-by: Suzuki K. Poulose <suzuki at in.ibm.com>
> 
> Simon,
> 
> Looks like there are no concerns about the approach in this patch.
> Could you please pull this in ?

Done.



More information about the kexec mailing list