This harmonizes efiboot and the various x86 bootloaders to use shared
code for printing the banner. By friendly coincidence, it also adds
support for specifying 'banner=' in arm efiboot's boot.cfg, as on x86.
ffs frontends to "ufs.c" now also define ufs_dinode_swap, ufs_indp_swap,
and FS_MAGIC (moved from ufs.c #if segments.) these are used to call
the right (32/64 bit) ffsv1/v2 version.
ufs.c 'struct file' gains f_swapped member. accessors for d_magic,
d_reclen, and d_ino are introduced (they need to be swapped.) sfter
reading an inode from disk, read_inode() may call ufs_dinode_swap().
indirect block number and caches may be swapped.
error handling in ffs_find_superblock() is cleaned up. (size is slightly
reduced on some ports with this part.)
defaults for new defines added to ufs.c. (XXX: we build ufs.c but i think
all the consumers don't use it, and we can stop building it.)
LFS support is not included.
add a cut-down copy of ffs_bswap.c from the kernel.
also enable bi-endian disklabel support in efiboot.
most ports build and sizes compared for platforms that don't enable this
code and all but one saw reduced code size. booted several platforms with
new boot code.
- dkcksum() and dkcksum_sized() move from subr_disk.c and from
libsa into libkern/dkcksum.c (which is missing _sized() version),
using the version from usr.sbin/disklabel.
- swap_disklabel() moves from subr_disk_mbr.c into libkern, now called
disklabel_swap(). (the sh3 version should be updated to use this.)
- DISKLABEL_EI becomes a first-class option with opt_disklabel.h.
- add libkern.h to libsa/disklabel.c.
this enables future work for bi-endian libsa/ufs.c (relevant for ffsv1,
ffsv2, lfsv1, and lfsv2), as well as making it possible for ports not
using subr_disk_mbr.c to include bi-endian disklabel support (which,
afaict, includes any disk on mbr-supporting platforms that do not have
an mbr as well as disklabel.)
builds successsfully on: alpha, i386, amd64, sun2, sun3, evbarm64,
evbarm64-eb, sparc, and sparc64. tested in anita on i386 and sparc,
testing in hardware on evbarm64*.
in 64 bit arithmetic. Pointed out by Rob Newberry.
Unfortunately this causes a code size increase breaking some boot blocks,
so conditionalize it and use 32 bit arithmetic if SA_DOSFS_NO_BIG_PART_SUPPORT
is defined.
* XXX Hack alert. GCC 8.3 mis-compiles this function and calls
* strncmp() with the wrong second pointer, as seen in PR#54703.
*
* Until the real cause is located, work around it by using -O1
* for this function.
this hack is restricted to i386.
opposite byte order (for arm EFI bootloader).
XXX
Currently, it is restricted to load_elf*.c. It would be nice if we can
recognize disklabel and filesystem of opposite byte order.
to update the boot-loader to push all modules required to support the
booted filesystem. We treat the fsmod string as a slash-separated list
of module names (relative to kern.module.path), rather than as a single
module path name.
Note that ffsv1 and ffsv2 are still exempted from the boot-loader's
auto-push, but the list of required filesystems is still noted in the
source.
Also note that arch/sandpoint needs a similar change. I have not made
this change because I am totally unable to test it.
Tested on my kernel with _no_ built-in file-systems and with the ffs
bootloader settings of fsmod enabled.
that passing variables to recursive makes with :q works as expected.
- Revert :Q to work as before.
- Adjust makefiles that use recursive make to use :q
Discussed on tech-toolchain@
XXX: pullup 8
correct the kernel name if he mistakenly typed pkboot on a static kernel,
without having to reboot the machine (currently the prekern sees it's a
static kernel and panics).
randomness, but on the contrary that increases it.
The size of the kernel sub-blocks is changed to be 1MB. This produces a
kernel with sections that are always < 2MB in size, that can fit a large
page.
Each section is put in a 2MB physical chunk. In this chunk, there is a
padding of approximately 1MB. The prekern uses a random offset aligned to
sh_addralign, to shift the section in physical memory.
For example, physical memory layout created by the bootloader for .text.4
and .rodata.0:
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
|+---------------+ |+---------------+ |
|| .text.4 | PAD || .rodata.0 | PAD |
|+---------------+ |+---------------+ |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
PA PA+2MB PA+4MB
Then, physical memory layout, after having been shifted by the prekern:
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| P +---------------+ | +---------------+ |
| A | .text.4 | PAD | PAD | .rodata.0 | PAD |
| D +---------------+ | +---------------+ |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
PA PA+2MB PA+4MB
The kernel maps these 2MB physical chunks with 2MB large pages. Therefore,
randomness is enforced at both the virtual and physical levels, and the
resulting entropy is higher than that of our current implementaion until
now.
The padding around the section is filled by the prekern. Not to consume
too much memory, the sections that are smaller than PAGE_SIZE are mapped
with normal pages - because there is no point in optimizing them. In these
normal pages, the same shift is applied.
This change has two additional advantages: (a) the cache attacks based on
the TLB are mostly mitigated, because even if you are able to determine
that a given page-aligned range is mapped as executable you don't know
where exactly within that range the section actually begins, and (b) given
that we are slightly randomizing the physical layout we are making some
rare physical attacks more difficult to conduct.
NOTE: after this change you need to update GENERIC_KASLR / prekern /
bootloader.
segments anymore. Initially I did this because I wanted to compress the
sections by reducing the padding between them; but we'll handle that
differently.
is used, and it does not break in any way the generic static loader. Then,
add a new "pkboot" command in the x86 bootloader, which boots a
GENERIC_KASLR kernel via the prekern. (See thread on tech-kern@.)
jmcneill