[U-Boot] Does U-boot support ASLR?

[Scott Wood]

On 02/09/2012 01: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.

Yes, there are insecure things you can do with the network interface --
if you're loading an image over TFTP and blindly booting that, obviously
that's an attack vector.

But you could instead be doing cryptographic validation of the loaded
image, or doing some sort of communication other than image loading.

As for tftpload not having length bounds, that's the kind of thing that
anyone trying to put together a secure loader would want to fix
(assuming they're using tftpload in the first place), but if such a hole
gets through, perhaps ASLR might make it more difficult to use that
length overrun to take control of the system (versus simply crash it).

>>> 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

I didn't say it was impenetrable, just more effort (depending on just
how poor the entropy is).

I suspect most of the situations where you'd actually use this would
involve a hardware random number generator, though, or some scheme to
store entropy across reboots.

>> It probably doesn't make sense as default behavior, but I could see it
>> being useful in some situations.
> 
> such as ?

When you can solve issues such as entropy generation, and are limiting
external exposure to interfaces that should be secure (but might have
bugs).  I can especially see people wanting this who are using hardware
secure boot mechanisms (i.e. U-Boot itself was cryptographically verified).

-Scott