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.
set or not, in the same way as libcompat.
- Specify OPT_MODULAR in the port Makefile instead of KERN_AS.
Now, KERN_AS=library is used for kernels without module(7) for all ports.
OK christos
These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.
HOWEVER! Some subsystems have
#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))
even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.
To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.
I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:
cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))
It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.
Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)
from Siddharth Muralee's initial work. This feature can detect several
kinds of memory bugs, and it's an excellent feature.
It can be enabled by uncommenting these three lines in GENERIC:
#makeoptions KASAN=1 # Kernel Address Sanitizer
#options KASAN
#no options SVS
The kernel is compiled without SVS, without DMAP and without PCPU area.
A shadow area is created at boot time, and it can cover the upper 128TB
of the address space. This area is populated gradually as we allocate
memory. With this design the memory consumption is kept at its lowest
level.
The compiler calls the __asan_* functions each time a memory access is
done. We verify whether this access is legal by looking at the shadow
area.
We declare our own special memcpy/memset/etc functions, because the
compiler's builtins don't add the __asan_* instrumentation.
Initially all the mappings are marked as valid. During dynamic
allocations, we add a redzone, which we mark as invalid. Any access on
it will trigger a kASan error message. Additionally, the compiler adds
a redzone on global variables, and we mark these redzones as invalid too.
The illegal-access detection works with a 1-byte granularity.
For now, we cover three areas:
- global variables
- kmem_alloc-ated areas
- malloc-ated areas
More will come, but that's a good start.
years. Adopt the new convention that it is call-site specific and that
it should be applied before moving the IP by personality routines, but
not during normal unwinding. Further discussion can be found in
LLVM's phabricator review D38680.
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.
