summaryrefslogtreecommitdiffstats
path: root/sys/lib/libsa/loadfile_elf.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Remove an unneeded variable.visa2020-10-261-3/+3
| | | | OK kettenis@
* Add an element to the marks array to store the virtual address of thekettenis2019-11-291-1/+2
| | | | | | entry point. ok mlarkin@, deraadt@
* Use arc4 to bit-spread the 512-byte random buffer over the .openbsd.randomdataderaadt2019-10-291-9/+8
| | | | | | | | | section, which has grown a fair bit with the introduction of retguard. Mortimer discovered the repeated 512-byte sequence as retguard keys, and this resolves the issue. (Chacha does not fit on the media, so 1.5K early drop RC4 is hopefully sufficient in our KARL link universe) Version crank the bootblocks. sysupgrade -s will install new bootblocks. ok djm mortimer
* change marks[] array to uint64_t, so the code can track full 64-bitderaadt2019-04-101-3/+3
| | | | | details from the ELF header instead of faking it. Proposal from mlarkin, tested on most architectures already
* move the .SUNW_ctf section name definition to exec_elf.h and document it in elf(5)jasper2016-09-171-2/+2
| | | | | feedback from guenther@ ok guenther@ kettenis@
* when loading the kernel binary, also load the .SUNW_ctf section when present,jasper2016-09-131-2/+3
| | | | | | which holds the CTF data. ok mpi@
* Extend the libsa loadfile(9) granularity to tell apart randomness from the restmiod2015-05-191-2/+7
| | | | | | | | | of the kernel, and extend the array filled by loadfile to report the location of the randomness area. This doesn't introduce any change for bootblocks (save for a slightly larger stack usage due to the larger array), for the new {LOAD,COUNT}_RANDOM bits are included in the {LOAD,COUNT}_ALL masks everything uses or computes from.
* Read the section header string table in the boot blocks' memory, not in themiod2014-10-261-2/+2
| | | | loaded image area.
* ddb: add support for DWARF line number decodingmatthew2014-10-091-4/+24
| | | | | | | | | | | | | | | | | | | | | | | | | This allows ddb's "trace" command to include file and line numbers: ddb{0}> trace Debugger() at Debugger+0x9 [../../../../arch/amd64/amd64/db_interface.c:405] ddb_sysctl() at ddb_sysctl+0x1b4 [../../../../ddb/db_usrreq.c:104] sys___sysctl() at sys___sysctl+0x216 [../../../../kern/kern_sysctl.c:229] syscall() at syscall+0x297 [../../../../sys/syscall_mi.h:84] --- syscall (number 202) --- end of kernel end trace frame: 0x7f7ffffcf1d7, count: -4 acpi_pdirpa+0x4117aa: For this to work, it requires using a new version of boot(8), and booting a kernel with the .debug_line section present (e.g., building with ``makeoptions DEBUG="-g"'' and then booting the bsd.gdb kernel instead of the stripped bsd kernel). Still a WIP, but no failure reports yet. Committing so further development and testing can happen in tree. prodding deraadt, guenther, mlarkin ok mpi
* Do not actually write to the area spanned by the PT_OPENBSD_RANDOMIZE ifmiod2014-02-251-5/+10
| | | | | LOAD_DATA is not set in flags; allows a two-pass kernel load using COUNT_KERNEL and then LOAD_KERNEL to work; similar to sparc loadfile_sparc.c 1.3.
* Try to load entropy data from disk:/etc/random.seed, and additionallyderaadt2013-12-281-1/+12
| | | | | | | use a MD-supplied random function. Then, insert this into the ELF openbsd.randomdata of the kernel, so that it has entropy right from the start. Some help from jsing for the softraid aspects. Also tested by phessler
* Allow the bootblocks to provide an optional Elfxx_Phdr check, and abort themiod2009-11-301-2/+8
| | | | file load if necessary. Will be used very shortly.
* First pass at removing clauses 3 and 4 from NetBSD licenses.ray2008-06-261-8/+1
| | | | | | | | | Not sure what's more surprising: how long it took for NetBSD to catch up to the rest of the BSDs (including UCB), or the amount of code that NetBSD has claimed for itself without attributing to the actual authors. OK deraadt@
* KNFjsing2008-05-081-9/+11
|
* Fix alignment - sizeof(long) does not always match the address size of thejsing2008-05-081-6/+6
| | | | | | ELF image being loaded. ok miod@
* Change ELF loader to use the LMA as the load address for theweingart2008-04-191-4/+4
| | | | | | | | various segments. Hopefully this will help remove various hacks in the boot loader in the future. This should have no effect on most architectures (as we tend to have LMA == VMA). ok drahn@, soft ok's various others.
* Pull out the ELF loadfile pieces from the standalone libraries, so thattom2007-05-301-0/+250
both 32- and 64-bit versions can be created (previously only one or the other could be built for a given boot loader). Use this to allow the i386 and amd64 boot blocks to boot both ELF32 and ELF64 kernels (i.e. amd64 boot blocks can now load i386 kernels, and vice versa). Obviously the system must support LONG mode in order to successfully run the amd64 kernel once it is loaded. Advice and discussions from/with dale@ (going back three years). Much testing nick@ and todd@; thanks.