Currently we map in the first 4 GiB of physical memory, directly into the kernel's virtual address space at 0-4 GiB. This means that null page is mapped in, and other low addresses in general can be clobbered. This can lead to some unsound code.

mm::read_phys uses read_volatile, read_volatile however requires the pointer to be aligned by the size of the pointer given when in debug mode.
This will break in situations like acpi discovery where table pointers are not necessarily 32 bit aligned in memory.

pub unsafe fn read_volatile<T>(src: *const T) -> T {
    if cfg!(debug_assertions) && !is_aligned_and_not_null(src) {
        // Not panicking to keep codegen impact smaller.
        abort();
    }
    // SAFETY: the caller must uphold the safety contract for `volatile_load`.
    unsafe { intrinsics::volatile_load(src) }
}

/// Checks whether `ptr` is properly aligned with respect to
/// `align_of::<T>()`.
pub(crate) fn is_aligned_and_not_null<T>(ptr: *const T) -> bool {
    !ptr.is_null() && ptr as usize % mem::align_of::<T>() == 0
}

active toolchain
----------------

nightly-x86_64-unknown-linux-gnu (default)
rustc 1.49.0-nightly (ffa2e7ae8 2020-10-24)

What happened:
I cloned the repository on commit 4e0c931, ran cargo run from the project root, which resulted in the following error:

lld-link.exe: error: could not open /filealign:0x1000: no such file or directory

Environment:

• Windows 10 v1909
• rustc 1.44.0-nightly
• LLVM v7.0.0

Expected outcomes:

• chocolate_milk notifying the user that lld-link is too old
• removing requirement on /filealign command line flag
• adding documentation about minimal supported lld-link version

I've checked LLVM versions 9 and 10, and chocolate milk successfully built binaries for the bootloader and the kernel.

Note: /filealign command line flag was added in llvm-svn: 361634, https://reviews.llvm.org/D62124

It's possible to have multiple memory affinities on the same domain. Relaxing this check causes the system to work just fine.

--- a/kernel/src/acpi.rs
+++ b/kernel/src/acpi.rs
@@ -454,8 +454,8 @@ unsafe fn parse_srat(ptr: PhysAddr) ->                // Log the affinity record
                if (flags & FLAGS_ENABLED) != 0 {
                    {+//+} assert!(memory_affinities.insert(domain, (base, [-size))-]
[-                            .is_none(),-]{+size)).is_none(),+} "Duplicate memory affinity domain");
                    {+memory_affinities.insert(domain, (base, size));+}
                }
            }```

Tested on PowerEdge T640 with Intel Xeon SIlver 4110

With QEMU 4.2 kernel panic because of wrong RSDP checksum.
In kernel/src/acpi.rs checksum calculation is not valid for ACPI 1.0.
QEMU seems to populate some 2.0 fields but marks the struct as rev 1.0 and calculate checksum accordingly.
Here is my RSDP table

{
  signature: [82, 83, 68, 32, 80, 84, 82, 32],
  checksum: 175,
  oem_id: [66, 79, 67, 72, 83, 32],
  revision: 0,
  rsdt_addr: 1073616209,
  length: 0,
  xsdt_addr: 0,
  extended_checksum: 95,
  reserved: [83, 77, 95]
}

Currently we map everything in the PE as RWX, we should honor the section permissions

If we're mapping multiple pages and during the mapping we fail, we should undo the failed mappings.

We could alternatively do an initial pass which validates that no mapping can fail during the mapping process, but this can be difficult to rely on as the physical memory requirement would need to be computed assuming all tables and pages which need to be created.

Hello,

I wanted to get the repo running but I encountered the error:

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/debug/chocolate_milk`
warning: the feature `track_caller` has been stable since 1.46.0 and no longer requires an attribute to enable
 --> /home/lhebendanz/Projects/chocolate_milk/shared/lockcell/src/lib.rs:4:22
  |
4 | #![feature(const_fn, track_caller, llvm_asm)]
  |                      ^^^^^^^^^^^^
  |
  = note: `#[warn(stable_features)]` on by default

warning: 1 warning emitted

    Finished release [optimized + debuginfo] target(s) in 0.01s
Error: "Base address for bootloader did not match expected"

My active toolchain is:

nightly-x86_64-unknown-linux-gnu (default)
rustc 1.49.0-nightly (91a79fb29 2020-10-07)

If a fatal interrupt or exception occurs, we should have a mechanism to stop all other running processors, and then take full control of hardware such that we can handle printing to serial, if we happened to panic while the print lock was held.

Currently we just let UDP packets buffer in the bind port lists, we should cap these to some reasonable number.

Currently DHCP blocks until a response. We should have timeouts and some retries