| Message ID | 1385006644-16024-1-git-send-email-joelf@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 11/20/2013 09:04 PM, Joel Fernandes wrote: > Kernel can silenty fail for DT-boot after the decompression stage, if DTB is > overwritten. Instead of simply failing, we detect the condition and print an > error. > > One may think that it is sufficient for the bootloader to place the DTB away > from kernel, but this is not the right fix because: (1) We add more dependence > to the bootloader's stupidity (2) the decompressed kernel end address is not > known to the loader. Also, we shouldn't depend on bootloader for silently > failing us, so we detect the condition and error out. If this problem happens, is there any guarantee that the kernel will still execute far enough to actually print this error message? Can the decompressor detect this condition instead?
On 11/21/2013 10:48 AM, Stephen Warren wrote: > On 11/20/2013 09:04 PM, Joel Fernandes wrote: >> Kernel can silenty fail for DT-boot after the decompression stage, if DTB is >> overwritten. Instead of simply failing, we detect the condition and print an >> error. >> >> One may think that it is sufficient for the bootloader to place the DTB away >> from kernel, but this is not the right fix because: (1) We add more dependence >> to the bootloader's stupidity (2) the decompressed kernel end address is not >> known to the loader. Also, we shouldn't depend on bootloader for silently >> failing us, so we detect the condition and error out. > > If this problem happens, is there any guarantee that the kernel will > still execute far enough to actually print this error message? Can the Yes, because till this point we don't depend on DTB yet. We're still just about to parse it. The problem detected here is the kernel overwriting the DTB, not the other way. > decompressor detect this condition instead? no because: (1) AIUI, decompressor doesn't have access to vmlinux symbols like _end. decompressor code is not linked with vmlinux. (2) The DTB pointer is physical and the _end symbol is virtual so assembly code has to do the physical to virtual translation before the cmp can be done which is more messy. thanks, -Joel
On 11/21/2013 12:48 PM, Joel Fernandes wrote: > On 11/21/2013 10:48 AM, Stephen Warren wrote: >> On 11/20/2013 09:04 PM, Joel Fernandes wrote: >>> Kernel can silenty fail for DT-boot after the decompression stage, if DTB is >>> overwritten. Instead of simply failing, we detect the condition and print an >>> error. >>> >>> One may think that it is sufficient for the bootloader to place the DTB away >>> from kernel, but this is not the right fix because: (1) We add more dependence >>> to the bootloader's stupidity (2) the decompressed kernel end address is not >>> known to the loader. Also, we shouldn't depend on bootloader for silently >>> failing us, so we detect the condition and error out. >> >> If this problem happens, is there any guarantee that the kernel will >> still execute far enough to actually print this error message? Can the > > Yes, because till this point we don't depend on DTB yet. We're still just about > to parse it. The problem detected here is the kernel overwriting the DTB, not > the other way. Ah yes, that makes sense. Thanks.
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c index f35906b..96c6964 100644 --- a/arch/arm/kernel/devtree.c +++ b/arch/arm/kernel/devtree.c @@ -21,6 +21,7 @@ #include <asm/cputype.h> #include <asm/setup.h> +#include <asm/sections.h> #include <asm/page.h> #include <asm/smp_plat.h> #include <asm/mach/arch.h> @@ -201,6 +202,13 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys) devtree = phys_to_virt(dt_phys); + if ((char *)devtree <= _end) { + early_print("Error: Device tree overwritten by kernel image\n"); + early_print("Please check your kernel config and/or bootloader\n"); + while (true) + ; + } + /* check device tree validity */ if (be32_to_cpu(devtree->magic) != OF_DT_HEADER) return NULL;
Kernel can silenty fail for DT-boot after the decompression stage, if DTB is overwritten. Instead of simply failing, we detect the condition and print an error. One may think that it is sufficient for the bootloader to place the DTB away from kernel, but this is not the right fix because: (1) We add more dependence to the bootloader's stupidity (2) the decompressed kernel end address is not known to the loader. Also, we shouldn't depend on bootloader for silently failing us, so we detect the condition and error out. Signed-off-by: Joel Fernandes <joelf@ti.com> --- arch/arm/kernel/devtree.c | 8 ++++++++ 1 file changed, 8 insertions(+)