Commit Graph

25 Commits

Author SHA1 Message Date
Mark Johnston
14327f5334 Tighten mapping protections on preloaded files on amd64.
- 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
2019-10-18 14:05:13 +00:00
Ed Maste
74cd06b42e Expose the kernel's build-ID through sysctl
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 <ali_mashtizadeh.com>
MFC after:	2 weeks
Relnotes:	Yes
Event:		Waterloo Hackathon 2019
Differential Revision:	https://reviews.freebsd.org/D20326
2019-06-04 13:07:10 +00:00
Ed Maste
c4698dec73 Add comment to explain kernel ldscript 0x200000 constant
Reported by:	linimon
2018-11-09 20:33:38 +00:00
Mateusz Guzik
10c51654ef amd64: tweak the read_frequently section
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.
2018-05-18 07:31:26 +00:00
Mateusz Guzik
726f22e081 amd64: align the .data.exclusive_cache_line section to 128
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.
2018-05-11 08:56:39 +00:00
Jonathan T. Looney
beb2406556 amd64: Protect the kernel text, data, and BSS by setting the RW/NX bits
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
2018-03-06 14:28:37 +00:00
Mateusz Guzik
cf558f10a7 Introduce __read_frequently
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
2017-09-06 20:32:49 +00:00
Ed Maste
bd4e40546c use INT3 instead of NOP for x86 binary padding
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
2017-03-19 00:22:13 +00:00
Mateusz Guzik
21b737495b Introduce __read_mostly and __exclusive_cache_line macros.
The intended use is to annotate frequently used globals which either rarely
change (and thus can be grouped in the same cacheline) or are an atomic counter
(which means it may benefit from being the only variable in the cacheline).

Linker script support is provided only for amd64. Architectures without it risk
having other variables put in, i.e. as if they were not annotated. This is
harmless from correctness point of view.

Reviewed by:	bde (previous version)
MFC after:	1 month
2017-01-27 14:53:09 +00:00
Ed Maste
9d99bb0a0a Use explicit 0x200000 instead of MAXPAGESIZE for the amd64 kernel physaddr
MAXPAGESIZE is not well defined by the GNU ld documentation.
Different linkers, and different versions of the same linker, use
different MAXPAGESIZE values. Current versions of GNU gold and LLVM's
lld use 4K. When set to 4K the kernel panics at boot due to an issue
with x86bios.

Here we want the kernel physaddr to be the amd64 superpage size, so use
that value (2MB) explicitly. With this change GNU gold and LLVM lld can
link a working amd64 kernel.

PR:		214718 (x86bios)
Differential Revision:	https://reviews.freebsd.org/D8610
2016-11-25 18:57:14 +00:00
Ed Maste
45eff3df96 remove CONSTRUCTORS from kernel linker scripts
The linker script CONSTRUCTORS keyword is only meaningful "when linking
object file formats which do not support arbitrary sections, such as
ECOFF and XCOFF"[1] and is ignored for other object file formats.

LLVM's lld does not yet accept (and ignore) CONSTRUCTORS, so just remove
CONSTRUCTORS from the linker scripts as it has no effect.

[1] https://sourceware.org/binutils/docs/ld/Output-Section-Keywords.html

Reviewed by:	kib
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D7343
2016-07-28 13:54:46 +00:00
Roger Pau Monné
7e748038cd amd64: set the correct LMA values
The current linker script generates program headers with VMA == LMA:

Entry point 0xffffffff802e7000
There are 6 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0xffffffff80200040 0xffffffff80200040
                 0x0000000000000150 0x0000000000000150  R E    8
  INTERP         0x0000000000000190 0xffffffff80200190 0xffffffff80200190
                 0x000000000000000d 0x000000000000000d  R      1
      [Requesting program interpreter: /red/herring]
  LOAD           0x0000000000000000 0xffffffff80200000 0xffffffff80200000
                 0x00000000010559b0 0x00000000010559b0  R E    200000
  LOAD           0x0000000001056000 0xffffffff81456000 0xffffffff81456000
                 0x0000000000132638 0x000000000052ecf8  RW     200000
  DYNAMIC        0x0000000001056000 0xffffffff81456000 0xffffffff81456000
                 0x00000000000000d0 0x00000000000000d0  RW     8
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RWE    8

This is fine for the FreeBSD loader, because it completely ignores p_paddr
and instead uses p_vaddr with a hardcoded offset. Other loaders however
acknowledge p_paddr (like the Xen ELF loader), in which case they will try
to load the kernel at the wrong place. Fix this by adding an AT keyword to
the first section specifying the physical address, other sections will
follow suit, so it ends up looking like:

Entry point 0xffffffff802e7000
There are 6 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0xffffffff80200040 0x0000000000200040
                 0x0000000000000150 0x0000000000000150  R E    8
  INTERP         0x0000000000000190 0xffffffff80200190 0x0000000000200190
                 0x000000000000000d 0x000000000000000d  R      1
      [Requesting program interpreter: /red/herring]
  LOAD           0x0000000000000000 0xffffffff80200000 0x0000000000200000
                 0x00000000010559b0 0x00000000010559b0  R E    200000
  LOAD           0x0000000001056000 0xffffffff81456000 0x0000000001456000
                 0x0000000000132638 0x000000000052ecf8  RW     200000
  DYNAMIC        0x0000000001056000 0xffffffff81456000 0x0000000001456000
                 0x00000000000000d0 0x00000000000000d0  RW     8
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RWE    8

Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS.

Sponsored by: Citrix Systems R&D
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D2783
2015-06-26 07:12:17 +00:00
Alan Cox
1c675a3bc3 The new binutils has correctly redefined MAXPAGESIZE on amd64 as 0x200000
instead of 0x100000.  As a side effect, an amd64 kernel now loads at
physical address 0x200000 instead of 0x100000.  This is probably for the
best because it avoids the use of a 2MB page mapping for the first 1MB of
the kernel that also spans the fixed MTRRs.  However, getmemsize() still
thinks that the kernel loads at 0x100000, and so the physical memory between
0x100000 and 0x200000 is lost.  Fix this problem by replacing the hard-wired
constant in getmemsize() by a symbol "kernphys" that is defined by the
linker script.

In collaboration with:	kib
2011-03-28 06:35:17 +00:00
Dimitry Andric
8ba66bb849 Sync sys/conf/ldscript.amd64 with the upstream version, preserving
FreeBSD-specific customizations (in particular, the addition of
_start_ctors and _stop_ctors).
2010-11-04 20:22:44 +00:00
Dimitry Andric
714d4612df Binutils commit 0c845abb5a0083c6deebc75975608237015badba increased
ELF_MAXPAGESIZE for amd64 from 0x00100000 to 0x00200000.  This caused
the kernel to be incorrectly linked, using the existing linker script,
resulting in a virtual address of 0xffffffff80000000 for the LOAD
program header.

The boot loader will load such a kernel at a real address of 0x00000000,
which either causes protection faults in btx, crashes the machine, or
(in case of a VMware guest) even makes it power down. :)

Fix this by partially synchronizing the amd64 linker script with
binutils own updated version, in particular replacing a hardcoded
value of 0x00100000 by CONSTANT(MAXPAGESIZE).
2010-11-04 18:57:51 +00:00
Dimitry Andric
491fb27448 Use new output format 'elf64-x86-64-freebsd' instead of 'elf64-x86-64',
and similarly 'elf64-sparc-freebsd' instead of 'elf64-sparc'.
2010-11-01 20:20:31 +00:00
Tim J. Robbins
907cb02fe9 Provide the _start_ctors and _stop_ctors symbols. As on i386, the addresses
of these are the start and end of the .ctors section.
2004-05-29 01:09:00 +00:00
Peter Wemm
b05deb9bc1 Sync up with the files in the hammer branch in the p4 tree to get basic
AMD64 support.  There is still more to add.
2003-05-01 02:59:24 +00:00
Poul-Henning Kamp
3fc473df24 Add two symbols start_ctors and stop_ctors to allow us to find the
.ctors section so we can call the constructors.
2003-01-06 07:37:15 +00:00
David E. O'Brien
616d2d5d48 Use the new freebsd output format from Binutils 2.13.1. 2002-10-11 19:38:04 +00:00
Peter Wemm
d7ffc0023d Remove hard coded magic load address. Now to change the load address,
we just have to change the pmap.h constants and ld will automatically
adapt based on the "kernbase" symbol.
2001-09-18 01:12:43 +00:00
Peter Wemm
d0e12656b8 Add $FreeBSD$
Make the alpha linker script more like the i386 version - delete the
/usr/local and egcs directories
2000-01-11 15:35:16 +00:00
Peter Wemm
5004cc2ecf Remove a rather bogus search path reference.. 1999-06-03 22:07:41 +00:00
David Greenman
8681b974c1 Increased kernel virtual address space to 1GB. NOTE: You MUST have fixed
bootblocks in order to boot the kernel after this! Also note that this
change breaks BSDI BSD/OS compatibility.
Also increased default NKPT to 17 so that FreeBSD can boot on machines
with >=2GB of RAM. Booting on machines with exactly 4GB requires other
patches, not included.
1999-03-11 18:28:46 +00:00
Peter Wemm
6b7a14ce57 Make the ELF kernel build produce a dynamic executable (!). This enables
the in-kernel linker to access the _DYNAMIC data for doing loadable elf
modules.  The alpha kernel is already done this way, I've borrowed some of
the hacks from there.

This is primarily aimed at the 3-stage boot process which is intended to
be able to do pre-loading of kernel modules.

Note that the entry point isn't 0xf0100000 any more, it'll be a little
further on - but this value is stored in the headers.  I don't think this
will be a problem, but I'm sure somebody will tell me if it is. :-)

I'm not sure if btxboot is going to like this, it doesn't do proper ELF
header checking and assumes that there are exactly two program header
entries and that they are both PT_LOAD entries - a bad assumption.
1998-09-30 12:14:39 +00:00