public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Jason Markley (ggsg) <jamarkle@ggsg.cisco.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Does U-boot support ASLR?
Date: Thu, 09 Feb 2012 15:03:46 -0500	[thread overview]
Message-ID: <4F3426A2.4010505@ggsg.cisco.com> (raw)
In-Reply-To: <201202091450.01316.vapier@gentoo.org>



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
>

  reply	other threads:[~2012-02-09 20:03 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-09 14:47 [U-Boot] Does U-boot support ASLR? Jason Markley
2012-02-09 15:13 ` Wolfgang Denk
2012-02-09 15:59   ` Mike Frysinger
     [not found]     ` <4F34125B.9070802@cisco.com>
2012-02-09 18:58       ` Mike Frysinger
2012-02-09 19:28         ` Scott Wood
2012-02-09 19:50           ` Mike Frysinger
2012-02-09 20:03             ` Jason Markley [this message]
2012-02-09 20:06             ` Scott Wood
2012-02-09 20:34               ` Mike Frysinger
2012-02-09 20:54                 ` Jason Markley
2012-02-09 19:55           ` Jason Markley
2012-02-09 20:31             ` Mike Frysinger
2012-02-09 22:16               ` Graeme Russ
2012-02-09 23:08                 ` Jason Markley
2012-02-10  0:09                   ` Graeme Russ
2012-02-10 11:44                   ` Wolfgang Denk
2012-02-09 19:56           ` Jason Markley
     [not found]   ` <4F33E93E.5070804@ggsg.cisco.com>
2012-02-10  7:07     ` Wolfgang Denk
2012-02-10 13:47       ` Jason Markley
2012-02-10 14:23         ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F3426A2.4010505@ggsg.cisco.com \
    --to=jamarkle@ggsg.cisco.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox