lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 21 Nov 2013 13:48:52 -0600
From:	Joel Fernandes <joelf@...com>
To:	Stephen Warren <swarren@...dotorg.org>
CC:	<linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>, <will.deacon@....com>,
	<rnayak@...com>, <santosh.shilimkar@...com>, <balbi@...com>
Subject: Re: [PATCH] ARM: kernel: Detect DTB overwrite and error out

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ