| 06fd8538 | 30-Nov-2012 |
Simon Glass <sjg@chromium.org> |
arm: Add CONFIG_DELAY_ENVIRONMENT to delay environment loading
This option delays loading of the environment until later, so that only the
default environment will be available to U-Boot.
This can
arm: Add CONFIG_DELAY_ENVIRONMENT to delay environment loading
This option delays loading of the environment until later, so that only the
default environment will be available to U-Boot.
This can address the security risk of untrusted data being used during boot.
Any time you load untrusted data you expose yourself to a bug in the
code. The attacker gets to choose the data so can sometimes carefully
craft it to exploit a bug. We try to avoid touching user-controlled
data during a verified boot unless strictly necessary. Since the
default environment is good enough in this case (or you would just
change it), this gets around the problem by just not loading the
environment.
When CONFIG_DELAY_ENVIRONMENT is defined, it is convenient to have a
run-time way of enabling loading of the environment. Add this to the
fdt as /config/delay-environment.
Note: This patch depends on http://patchwork.ozlabs.org/patch/194342/
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
show more ...
|
| eae78c34 | 30-Nov-2012 |
Simon Glass <sjg@chromium.org> |
arm: Move fdt check earlier so that board_early_init_f() can use it
We want to use the fdt inside board_early_init_f(), so check for its
presence earlier in the pre-reloc init sequence.
So far ARM
arm: Move fdt check earlier so that board_early_init_f() can use it
We want to use the fdt inside board_early_init_f(), so check for its
presence earlier in the pre-reloc init sequence.
So far ARM and microblaze are the only only ones that use
CONFIG_OF_CONTROL. Microblaze does not have the same init loop, and in
particular does not have the board_early_init_f() call. So a patch for
microblaze would have no meaning.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 724cdffc | 30-Nov-2012 |
Gabe Black <gabeblack@chromium.org> |
arm: Keep track of the tlb size as well as its location
It may be necessary to know where the TLB area ends as well as where it
starts. This allows board code to complete a secure memory erase witho
arm: Keep track of the tlb size as well as its location
It may be necessary to know where the TLB area ends as well as where it
starts. This allows board code to complete a secure memory erase without
destroying the page tables.
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| d702b081 | 16-May-2012 |
SRICHARAN R <r.sricharan@ti.com> |
ARM: cache: Move the cp15 CR register read before flushing the cache.
The following is the cleanup sequence in arch/arm/cpu/armv7/cpu.c
int cleanup_before_linux(void)
{
...
...
dcache_disable();
ARM: cache: Move the cp15 CR register read before flushing the cache.
The following is the cleanup sequence in arch/arm/cpu/armv7/cpu.c
int cleanup_before_linux(void)
{
...
...
dcache_disable();
v7_outer_cache_disable();
invalidate_dcache_all();
}
1) invalidate_dcache_all call expects that all the caches has been
flushed, invalidated and there are no dirty entries prior to its
execution. In the above sequence dcache_disable() flushes, invalidates
the caches and turns off the mmu. But after it cleanups the cache
and before the mmu is disabled there is a cp_delay() function which
has STR instruction. On certain cores like the cortex-a15, cache hit
and a write can happen to a cache line even when the dcache is
disabled. So the above mentioned STR instruction creates a dirty entry
after cleaning. The mmu gets disabled after this.
2) invalidate_dcache_all invalidates the cache lines. Again on
cores like cortex-a15, invalidate instruction flushes the dirty
line as well. So some times the dirty line from sequence 1
can corrupt the memory resulting in a crash.
Fixing this by moving the get_cr() and cp_delay() calls before
cleaning up the cache, thus avoiding the dirty entry.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
show more ...
|