Link [ NetBSD | NetBSD OpenGrok source search | PR fulltext-search | Summary of daily snapshot builds | history of daily build result | pkgsrc commit viewer ]


   
        usage: [branch:branch] [user:user] [path@revision] keyword [... [-excludekeyword [...]]] (e.g. branch:MAIN sys/arch/arm, if_wm.c@1.234 )




switch to index mode

recent branches: MAIN (53m)  netbsd-10 (4d)  netbsd-9 (4d)  netbsd-8 (9d) 

2024-05-20 16:57:54 UTC Now

2020-02-12 20:10:10 UTC netbsd-9 commitmail json YAML

Pull up following revision(s) (requested by riastradh in ticket #705):

sys/arch/aarch64/aarch64/aarch64_machdep.c: revision 1.35
sys/stand/efiboot/efifdt.c: revision 1.20
sys/stand/efiboot/efifdt.h: revision 1.7
sys/arch/aarch64/include/machdep.h: revision 1.9
sys/stand/efiboot/efiboot.h: revision 1.11
sys/arch/arm/arm32/arm32_machdep.c: revision 1.129
sys/arch/arm/include/arm32/machdep.h: revision 1.30
sys/stand/efiboot/exec.c: revision 1.12
sys/arch/evbarm/fdt/fdt_machdep.c: revision 1.65
sys/stand/efiboot/version: revision 1.14
sys/stand/efiboot/boot.c: revision 1.19

New function cpu_startup_hook on arm.

Called at end of cpu_startup.  Can be defined in, e.g., evbarm to do
additional stuff after cpu_startup.  Defined as a weak alias to a
function that does nothing, so optional.
ok jmcneill

Implement rndseed support in efiboot and fdt arm.

The EFI environment variable `rndseed' specifies the path to the
random seed.  It is loaded only for fdt platforms at the moment.
Since the rndseed (an rndsave_t object as defined in <sys/rndio.h>)
is 536 bytes long (for hysterical raisins), and to avoid having to
erase parts of the fdt tree, we load it into a physical page whose
address is passed in the fdt tree, rather than passing the content of
the file as an fdt node directly; the kernel then reserves the page
from uvm, and maps it into kva to call rnd_seed.

For now, the only kernel that does use efiboot with fdt is evbarm,
which knows to handle the rndseed.  Any new kernels that use efiboot
with fdt must do the same; otherwise uvm may hand out the page with
the secret key on it for a normal page allocation in the kernel --
which should be OK if there are no kernel memory disclosure bugs, but
would lead to worse consequences than simply loading the seed late in
userland with /etc/rc.d/random_seed otherwise.

ok jmcneill

(martin)