src/sys/conf/ldscript.amd64, branch release/13.1.0

amd64: do not assume that kernel is loaded at 2M physical

2021-08-23T23:21:13Z

(cherry picked from commit e18380e341410ce70d97560a22827591f4b2d373)

Unobfuscate "KERNLOAD" parameter on amd64. This change lines-up amd64 with the

2020-11-25T23:19:01Z

i386 and the rest of supported architectures by defining KERNLOAD in the vmparam.h and getting rid of magic constant in the linker script, which albeit documented via comment but isn't programmatically accessible at a compile time. Use KERNLOAD to eliminate another (matching) magic constant 100 lines down inside unremarkable TU "copy.c" 3 levels deep in the EFI loader tree. Reviewed by: markj Approved by: markj MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D27355

Tighten mapping protections on preloaded files on amd64.

2019-10-18T14:05:13Z

- We load the kernel at 0x200000. Memory below that address need not be executable, so do not map it as such. - Remove references to .ldata and related sections in the kernel linker script. They come from ld.bfd's default linker script, but are not used, and we now use ld.lld to link the amd64 kernel. lld does not contain a default linker script. - Pad the .bss to a 2MB as we do between .text and .data. This forces the loader to load additional files starting in the following 2MB page, preserving the use of superpage mappings for kernel data. - Map memory above the kernel image with NX. The kernel linker now upgrades protections as needed, and other preloaded file types (e.g., entropy, microcode) need not be mapped with execute permissions in the first place. Reviewed by: kib MFC after: 1 month Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D21859

Expose the kernel's build-ID through sysctl

2019-06-04T13:07:10Z

After our migration (of certain architectures) to lld the kernel is built with a unique build-ID. Make it available via a sysctl and uname(1) to allow the user to identify their running kernel. Submitted by: Ali Mashtizadeh MFC after: 2 weeks Relnotes: Yes Event: Waterloo Hackathon 2019 Differential Revision: https://reviews.freebsd.org/D20326

Add comment to explain kernel ldscript 0x200000 constant

2018-11-09T20:33:38Z

Reported by: linimon

amd64: tweak the read_frequently section

2018-05-18T07:31:26Z

1. align to 128 bytes to avoid possible waste from the preceeding section 2. sort entries by alignment SORT_BY_ALIGNMENT, plugging the holes (most entries are one byte in size, but they got interleaved with bigger ones) Interestingly I was looking for a feature of the sort earlier and failed to find it. It turns out the script was already utilizing sorting in other places, so shame on me. Thanks for Travis Geiselbrecht for pointing me at the feature.

amd64: align the .data.exclusive_cache_line section to 128

2018-05-11T08:56:39Z

This aligns the section itself compared to other sections, does not change internal alignment of fields stored inside. This may or may not come later. The motivation is partially combating adverse effects of the adjacent cache line prefetcher. Without the annotation part of read_mostly section was on the line of fire.

amd64: Protect the kernel text, data, and BSS by setting the RW/NX bits

2018-03-06T14:28:37Z

correctly for the data contained on each memory page. There are several components to this change: * Add a variable to indicate the start of the R/W portion of the initial memory. * Stop detecting NX bit support for each AP. Instead, use the value from the BSP and, if supported, activate the feature on the other APs just before loading the correct page table. (Functionally, we already assume that the BSP and all APs had the same support or lack of support for the NX bit.) * Set the RW and NX bits correctly for the kernel text, data, and BSS (subject to some caveats below). * Ensure DDB can write to memory when necessary (such as to set a breakpoint). * Ensure GDB can write to memory when necessary (such as to set a breakpoint). For this purpose, add new MD functions gdb_begin_write() and gdb_end_write() which the GDB support code can call before and after writing to memory. This change is not comprehensive: * It doesn't do anything to protect modules. * It doesn't do anything for kernel memory allocated after the kernel starts running. * In order to avoid excessive memory inefficiency, it may let multiple types of data share a 2M page, and assigns the most permissions needed for data on that page. Reviewed by: jhb, kib Discussed with: emaste MFC after: 2 weeks Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D14282

Introduce __read_frequently

2017-09-06T20:32:49Z

While __read_mostly groups variables together, their placement is not specified. In particular 2 frequently used variables can end up in different lines. This annotation is only expected to be used for variables read all the time, e.g. on each syscall entry. MFC after: 1 week

use INT3 instead of NOP for x86 binary padding

2017-03-19T00:22:13Z

We should never end up executing the inter-function padding, so we are better off faulting than silently carrying on to whatever function happens to be next. Note that LLD will soon do this by default (although it currently pads with zeros). Reviewed by: dim, kib MFC after: 1 month Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D10047