From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Date: Thu, 9 Feb 2012 14:50:00 -0500 Subject: [U-Boot] Does U-boot support ASLR? In-Reply-To: <4F341E47.9010306@freescale.com> References: <4F33DC75.4040002@ggsg.cisco.com> <201202091358.54739.vapier@gentoo.org> <4F341E47.9010306@freescale.com> Message-ID: <201202091450.01316.vapier@gentoo.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. > > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: