From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Markley (ggsg) Date: Thu, 09 Feb 2012 15:03:46 -0500 Subject: [U-Boot] Does U-boot support ASLR? In-Reply-To: <201202091450.01316.vapier@gentoo.org> References: <4F33DC75.4040002@ggsg.cisco.com> <201202091358.54739.vapier@gentoo.org> <4F341E47.9010306@freescale.com> <201202091450.01316.vapier@gentoo.org> Message-ID: <4F3426A2.4010505@ggsg.cisco.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 2/9/12 2:50 PM, Mike Frysinger wrote: > On Thursday 09 February 2012 14:28:07 Scott Wood wrote: >> On 02/09/2012 12:58 PM, Mike Frysinger wrote: >>> On Thursday 09 February 2012 13:37:15 Jason Markley wrote: >>>> I agree any proposal would need to be accompanied by good reasoning. >>>> I'm honestly a little confused as to why a generally accepted security >>>> feature such as ASLR would NOT be useful for u-boot. U-boot has the >>>> capability to interact with the outside world via the network as well as >>>> the console. When using the U-boot API, it also remains resident in >>>> memory. Wouldn't something like ASLR enhance the security posture of >>>> U-boot in those situations? >>> u-boot is running in supervisor mode / ring 0 / etc... you have full >>> access to the hardware with a simple `mw` command. randomizing the >>> address base of u-boot doesn't gain you anything. so no, i see no >>> advantage of u-boot itself utilizing ASLR regardless of what it >>> interacts with. >> This assumes that the full command line interface is enabled, and is the >> mechanism of interaction in question. It doesn't apply to interactions >> over the network, special serial protocols, etc. > network/serial loads do no file length checks. `tftpload 0` will write until > the server stops sending. not to mention there is no secure communication > between u-boot and the server. And having TFTP as an option in such a 'secure' boot loader would probably not make it past the checks necessary. So if it helps, assume that when someone is wanting to use ASLR, they also would configure U-boot to not have the tftpload command available. -Jason > >>> ignoring this, there are two fundamental issues with ASLR: >>> - this early on, u-boot has very little (if no) entropy, so any attempts >>> to >>> >>> generate random numbers are going to be fairly predictable >> This doesn't apply if there's a hardware random number generator -- and >> even poor entropy is more effort to guess than a fixed address. > not when you know the starting point and can brute force it through > >> It probably doesn't make sense as default behavior, but I could see it >> being useful in some situations. > such as ? > -mike > > > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot >