* [U-Boot] Does U-boot support ASLR?
2012-02-09 19:28 ` Scott Wood
@ 2012-02-09 19:50 ` Mike Frysinger
2012-02-09 20:03 ` Jason Markley
2012-02-09 20:06 ` Scott Wood
2012-02-09 19:55 ` Jason Markley
2012-02-09 19:56 ` Jason Markley
2 siblings, 2 replies; 20+ messages in thread
From: Mike Frysinger @ 2012-02-09 19:50 UTC (permalink / raw)
To: u-boot
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: <http://lists.denx.de/pipermail/u-boot/attachments/20120209/77da5576/attachment.pgp>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [U-Boot] Does U-boot support ASLR?
2012-02-09 19:50 ` Mike Frysinger
@ 2012-02-09 20:03 ` Jason Markley
2012-02-09 20:06 ` Scott Wood
1 sibling, 0 replies; 20+ messages in thread
From: Jason Markley @ 2012-02-09 20:03 UTC (permalink / raw)
To: u-boot
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
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [U-Boot] Does U-boot support ASLR?
2012-02-09 19:50 ` Mike Frysinger
2012-02-09 20:03 ` Jason Markley
@ 2012-02-09 20:06 ` Scott Wood
2012-02-09 20:34 ` Mike Frysinger
1 sibling, 1 reply; 20+ messages in thread
From: Scott Wood @ 2012-02-09 20:06 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [U-Boot] Does U-boot support ASLR?
2012-02-09 20:06 ` Scott Wood
@ 2012-02-09 20:34 ` Mike Frysinger
2012-02-09 20:54 ` Jason Markley
0 siblings, 1 reply; 20+ messages in thread
From: Mike Frysinger @ 2012-02-09 20:34 UTC (permalink / raw)
To: u-boot
On Thursday 09 February 2012 15:06:48 Scott Wood wrote:
> 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)
which is my point -- u-boot is so completely opening, throwing ASLR in there
makes no sense. there are plenty of ways to break the system.
> 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).
if you can overwrite any of u-boot, then i doubt this is that hard. this is
what NOP slides are very good at.
> >> 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).
this isn't an example of how ASLR would be useful
-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: <http://lists.denx.de/pipermail/u-boot/attachments/20120209/8374d34f/attachment.pgp>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [U-Boot] Does U-boot support ASLR?
2012-02-09 20:34 ` Mike Frysinger
@ 2012-02-09 20:54 ` Jason Markley
0 siblings, 0 replies; 20+ messages in thread
From: Jason Markley @ 2012-02-09 20:54 UTC (permalink / raw)
To: u-boot
On 2/9/12 3:34 PM, Mike Frysinger wrote:
> On Thursday 09 February 2012 15:06:48 Scott Wood wrote:
>> 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)
> which is my point -- u-boot is so completely opening, throwing ASLR in there
> makes no sense. there are plenty of ways to break the system.
There are plenty of ways to break any system. Isn't the whole idea of
security that you simply make it harder for particular attack vectors to
be fruitful? You're not going to be able to prevent EVERY attack, so
should we just not bother with security at all?
>
>> 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).
> if you can overwrite any of u-boot, then i doubt this is that hard. this is
> what NOP slides are very good at.
>
>>>> 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).
> this isn't an example of how ASLR would be useful
Isn't ASLR useful in the sense that it does what ASLR was created to
do? make it 'harder' (not impossible, but another layer of difficulty)
for attacking code to determine where particular code lives?
Are you arguing that ASLR isn't useful for anything at all? Or just
useful for U-boot? If anything at all, why is it implemented in so many
other places? If just U-boot, isn't plugging one small hole, even
though larger holes exist still making progress?
-Jason
> -mike
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [U-Boot] Does U-boot support ASLR?
2012-02-09 19:28 ` Scott Wood
2012-02-09 19:50 ` Mike Frysinger
@ 2012-02-09 19:55 ` Jason Markley
2012-02-09 20:31 ` Mike Frysinger
2012-02-09 19:56 ` Jason Markley
2 siblings, 1 reply; 20+ messages in thread
From: Jason Markley @ 2012-02-09 19:55 UTC (permalink / raw)
To: u-boot
On 2/9/12 2:28 PM, Scott Wood wrote:
> On 02/09/2012 12:58 PM, Mike Frysinger wrote:
>> On Thursday 09 February 2012 13:37:15 Jason Markley wrote:
>>
>> please don't top post, and keep the mailing list in cc
>>
>>> 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.
Agree with Scott. A board that wanted to use ASLR for U-boot would
probably also want to restrict the cmd set available to the user.
>
>> 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.
Totally agree.
>
>> - scripts that u-boot runs at boot time often times need a chunk of memory to
>> load and boot stuff out of. if u-boot could randomly be in the middle of that,
>> then your board now randomly fails to boot. the only way around that would be
>> to have u-boot do virtual addresses, and that's clearly a non-starter.
> You'd just need to document which areas U-Boot could be in, and which
> areas are free for user use.
>
> It probably doesn't make sense as default behavior, but I could see it
> being useful in some situations.
>
> -Scott
>
Exactly. There would be a range of memory that U-boot could be in, but
you would still be able to have a large chunk of space for scripts to
load and boot from. Depending on how much memory a particular board
has, the 'chunk' required could be small in comparison to the available
memory. Agree, that if the board has little to no 'available' memory to
randomize because it needs all it's available memory for loading an OS,
that ASLR on such a platform doesn't make sense, but who's to say it
wouldn't be useful for other boards?
-Jason
^ permalink raw reply [flat|nested] 20+ messages in thread
* [U-Boot] Does U-boot support ASLR?
2012-02-09 19:55 ` Jason Markley
@ 2012-02-09 20:31 ` Mike Frysinger
2012-02-09 22:16 ` Graeme Russ
0 siblings, 1 reply; 20+ messages in thread
From: Mike Frysinger @ 2012-02-09 20:31 UTC (permalink / raw)
To: u-boot
On Thursday 09 February 2012 14:55:09 Jason Markley wrote:
> that ASLR on such a platform doesn't make sense, but who's to say it
> wouldn't be useful for other boards?
you have yet to show how it'd be useful. as the person proposing the new
feature, it's on you to show why it isn't just a waste of time.
-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: <http://lists.denx.de/pipermail/u-boot/attachments/20120209/2babebf8/attachment.pgp>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [U-Boot] Does U-boot support ASLR?
2012-02-09 20:31 ` Mike Frysinger
@ 2012-02-09 22:16 ` Graeme Russ
2012-02-09 23:08 ` Jason Markley
0 siblings, 1 reply; 20+ messages in thread
From: Graeme Russ @ 2012-02-09 22:16 UTC (permalink / raw)
To: u-boot
Hi Guys,
My 2c worth...
The thought of applying ASLR to improve security is pointless unless you
have identified a reason to do so. You can't just apply a security
hardening technique willy-nilly and expect you security to improve. The
security of a system is equal to the weakest link and no amount of
strengthening the other links will improve security
Remember, U-Boot is a boot-loader. It is very transitory. Think about how
an attacker could exploit U-Boot (Hint: 10s after booting, they can't)
Network: Hit it with IP packets - But U-Boot only activates network code
on as as-needed basis (typically when someone runs a net command like tftp
etc) so you already have U-Boot shell access anyway
Serial: Buffer overruns on commands - U-Boot will crash and the board
reboots and again, you probably already had/have shell access
So it starts to boil down to protecting access to the shell - Access to
the shell opens up all sorts of possibilities such as changing environment
variables (including scripts) up to completely replacing the U-Boot image
So my thought would be, if you want to improve U-Boot security, perhaps
implement password protection on the shell
Regards,
Graeme
^ permalink raw reply [flat|nested] 20+ messages in thread
* [U-Boot] Does U-boot support ASLR?
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
0 siblings, 2 replies; 20+ messages in thread
From: Jason Markley @ 2012-02-09 23:08 UTC (permalink / raw)
To: u-boot
On 2/9/12 5:16 PM, Graeme Russ wrote:
> Hi Guys,
>
> My 2c worth...
>
> The thought of applying ASLR to improve security is pointless unless you
> have identified a reason to do so. You can't just apply a security
> hardening technique willy-nilly and expect you security to improve. The
> security of a system is equal to the weakest link and no amount of
> strengthening the other links will improve security
Agreed, but in the grand scheme of things, does that mean the
maintainers of U-boot will ONLY allow patches in that fix the biggest
security hole that currently exists? If someone desires to patch a
small hole because they have a reason to, or desire to, but it's
currently the biggest hole out there, should said person be denied the
opportunity to present a patch for the hole they've identified?
>
> Remember, U-Boot is a boot-loader. It is very transitory. Think about how
> an attacker could exploit U-Boot (Hint: 10s after booting, they can't)
What about the U-boot API infrastructure? Isn't that designed to allow
a program that U-boot loads to call back into U-boot to perform some
function? Doesn't that mean U-boot is no longer transitory?
-Jason
>
> Network: Hit it with IP packets - But U-Boot only activates network code
> on as as-needed basis (typically when someone runs a net command like tftp
> etc) so you already have U-Boot shell access anyway
>
> Serial: Buffer overruns on commands - U-Boot will crash and the board
> reboots and again, you probably already had/have shell access
>
> So it starts to boil down to protecting access to the shell - Access to
> the shell opens up all sorts of possibilities such as changing environment
> variables (including scripts) up to completely replacing the U-Boot image
>
> So my thought would be, if you want to improve U-Boot security, perhaps
> implement password protection on the shell
>
> Regards,
>
> Graeme
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [U-Boot] Does U-boot support ASLR?
2012-02-09 23:08 ` Jason Markley
@ 2012-02-10 0:09 ` Graeme Russ
2012-02-10 11:44 ` Wolfgang Denk
1 sibling, 0 replies; 20+ messages in thread
From: Graeme Russ @ 2012-02-10 0:09 UTC (permalink / raw)
To: u-boot
Hi Jason,
On Fri, Feb 10, 2012 at 10:08 AM, Jason Markley (ggsg)
<jamarkle@ggsg.cisco.com> wrote:
>
>
> On 2/9/12 5:16 PM, Graeme Russ wrote:
>> Hi Guys,
>>
>> My 2c worth...
>>
>> The thought of applying ASLR to improve security is pointless unless you
>> have identified a reason to do so. You can't just apply a security
>> hardening technique willy-nilly and expect you security to improve. The
>> security of a system is equal to the weakest link and no amount of
>> strengthening the other links will improve security
> Agreed, but in the grand scheme of things, does that mean the
> maintainers of U-boot will ONLY allow patches in that fix the biggest
> security hole that currently exists? ?If someone desires to patch a
> small hole because they have a reason to, or desire to, but it's
> currently the biggest hole out there, should said person be denied the
> opportunity to present a patch for the hole they've identified?
Of course not, but ASLR would introduce a complexity that is not in
proportion to the problem being solved.
No-one is ever prevented from presenting a patch - You are more than
welcome to write it and post it to the list. Have a look through the
archives, plenty of patches have been presented that have been regected
(mine included)
>> Remember, U-Boot is a boot-loader. It is very transitory. Think about how
>> an attacker could exploit U-Boot (Hint: 10s after booting, they can't)
> What about the U-boot API infrastructure? ?Isn't that designed to allow
> a program that U-boot loads to call back into U-boot to perform some
> function? ?Doesn't that mean U-boot is no longer transitory?
Don't mistake U-Boot having a stand-alone API as being the same as U-Boot
being an OS. In theory you could write a malicious stand-alone application,
store it on an SD card, load it up and run it but you have console access,
so you are already well past any effective security ASLR or NX etc would
provide anyway.
U-Boot is a boot loader - It initialises enough hardware to get the OS
loaded and running and thats it. As I understand it, the API is there
primarily for extended test suites designed to test hardware during
manufacturing.
And U-Boot is a single user environment - You don't need to exploit it in
order to get 'root' access - If you have command line, you have root. If
you really wanted to harden U-Boot against a malicous user, I would look
at providing protected access to the shell first.
So I think you need to have a good think about what ASLR is designed to
mitigate (privilege escalation due to buffer overrun and arbitrary code
execution) and think of how it applies to U-Boot (which it does not as
there is not multiple privilege levels to escalate between)
Regards,
Graeme
^ permalink raw reply [flat|nested] 20+ messages in thread
* [U-Boot] Does U-boot support ASLR?
2012-02-09 23:08 ` Jason Markley
2012-02-10 0:09 ` Graeme Russ
@ 2012-02-10 11:44 ` Wolfgang Denk
1 sibling, 0 replies; 20+ messages in thread
From: Wolfgang Denk @ 2012-02-10 11:44 UTC (permalink / raw)
To: u-boot
Dear Jason,
In message <4F3451DE.3050503@ggsg.cisco.com> you wrote:
>
> Agreed, but in the grand scheme of things, does that mean the
> maintainers of U-boot will ONLY allow patches in that fix the biggest
> security hole that currently exists? If someone desires to patch a
> small hole because they have a reason to, or desire to, but it's
> currently the biggest hole out there, should said person be denied the
> opportunity to present a patch for the hole they've identified?
Well, we always have to ask ourself what the benefit of any patch is:
Is it useful to soemone? Does it hurt others? Does it improve U-Boot
in any significant way? Does it make maintainance of U-Boot easier or
more difficult? etc.
In case of ASLR, my personal feeling is that there are tons and tons
of other areas that would be way more important to "harden" U-Boot.
Adding ASLR sounds to me just like a buzzword you can put on some list
of features, where it does not help you anything except maybe to
collect some brownie points.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Nobody goes to that restaurant anymore. It's too crowded.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [U-Boot] Does U-boot support ASLR?
2012-02-09 19:28 ` Scott Wood
2012-02-09 19:50 ` Mike Frysinger
2012-02-09 19:55 ` Jason Markley
@ 2012-02-09 19:56 ` Jason Markley
2 siblings, 0 replies; 20+ messages in thread
From: Jason Markley @ 2012-02-09 19:56 UTC (permalink / raw)
To: u-boot
On 2/9/12 2:28 PM, Scott Wood wrote:
> On 02/09/2012 12:58 PM, Mike Frysinger wrote:
>> On Thursday 09 February 2012 13:37:15 Jason Markley wrote:
>>
>> please don't top post, and keep the mailing list in cc
>>
>>> 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.
Agree with Scott. A board that wanted to use ASLR for U-boot would
probably also want to restrict the cmd set available to the user.
>
>> 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.
Totally agree.
>
>> - scripts that u-boot runs at boot time often times need a chunk of memory to
>> load and boot stuff out of. if u-boot could randomly be in the middle of that,
>> then your board now randomly fails to boot. the only way around that would be
>> to have u-boot do virtual addresses, and that's clearly a non-starter.
> You'd just need to document which areas U-Boot could be in, and which
> areas are free for user use.
>
> It probably doesn't make sense as default behavior, but I could see it
> being useful in some situations.
>
> -Scott
>
Exactly. There would be a range of memory that U-boot could be in, but
you would still be able to have a large chunk of space for scripts to
load and boot from. Depending on how much memory a particular board
has, the 'chunk' required could be small in comparison to the available
memory. Agree, that if the board has little to no 'available' memory to
randomize because it needs all it's available memory for loading an OS,
that ASLR on such a platform doesn't make sense, but who's to say it
wouldn't be useful for other boards?
-Jason
^ permalink raw reply [flat|nested] 20+ messages in thread