mirror of
https://chromium.googlesource.com/crosvm/crosvm
synced 2024-11-28 17:44:10 +00:00
No description
b4244d3952
Previously, we were loading ELF kernels at the provided kernel_start address plus the p_paddr (physical address) field of each program header. This resulted in the kernel being loaded after a big gap of zero bytes, which accidentally worked on x86_64 because 0x00 0x00 encodes a valid instruction, and the entry point was at the beginning of the first section, so execution would effectively "nop slide" its way from the supposed entry point all the way to the actual beginning of the correct code. In addition, the Linux kernel entry point is compiled as position-independent code, so the mismatched address did not matter. Fix this by loading ELF kernels at whatever physical address they specify, without adding any extra offset. The load_kernel() function still accepts a start address, but this is now used simply to verify that the ELF file does not try to load any sections outside of the desired kernel region. As a demonstration, we can look at the instructions at the kernel's declared entry point (0x1000000 for a normal x86-64 Linux kernel in ELF format) by attaching to the gdb stub and running: (gdb) disas 0x1000000,+8 With the old behavior, we get purely 0x00 0x00 opcodes, decoding as: 0x0000000001000000: add BYTE PTR [rax],al 0x0000000001000002: add BYTE PTR [rax],al 0x0000000001000004: add BYTE PTR [rax],al 0x0000000001000006: add BYTE PTR [rax],al With the new behavior, we get the correct entry point instructions: 0x0000000001000000: lea rsp,[rip+0x1203f51] # 0x2203f58 0x0000000001000007: lea rdi,[rip+0xfffffffffffffff2] # 0x1000000 BUG=b:234155022 TEST=cargo test -p kernel_loader TEST=Boot x86-64 ELF vmlinux kernel Change-Id: Iae4c8db022674e6311e54dffe479a1ed430a1ef4 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3673612 Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Anton Romanov <romanton@google.com> Commit-Queue: Daniel Verkamp <dverkamp@chromium.org> Reviewed-by: Alexandre Courbot <acourbot@chromium.org> |
||
---|---|---|
.cargo | ||
.devcontainer | ||
.github | ||
aarch64 | ||
acpi_tables | ||
arch | ||
argh_helpers | ||
base | ||
bin | ||
bit_field | ||
broker_ipc | ||
ci/kokoro | ||
common | ||
cros_async | ||
crosvm-fuzz | ||
crosvm_control | ||
crosvm_plugin | ||
devices | ||
disk | ||
docs/book | ||
fuse | ||
gpu_display | ||
hypervisor | ||
infra | ||
integration_tests | ||
io_uring | ||
kernel_cmdline | ||
kernel_loader | ||
kvm | ||
kvm_sys | ||
libcras_stub | ||
linux_input_sys | ||
logo | ||
media | ||
metrics | ||
net_sys | ||
net_util | ||
power_monitor | ||
protos | ||
qcow_utils | ||
resources | ||
rutabaga_gfx | ||
seccomp | ||
serde_keyvalue | ||
src | ||
system_api_stub | ||
tests | ||
third_party | ||
tools | ||
tpm2 | ||
tpm2-sys | ||
tracing | ||
tube_transporter | ||
usb_sys | ||
usb_util | ||
vfio_sys | ||
vhost | ||
virtio_sys | ||
vm_control | ||
vm_memory | ||
win_audio | ||
win_util | ||
x86_64 | ||
.dockerignore | ||
.gitignore | ||
.gitmodules | ||
.rustfmt.toml | ||
ARCHITECTURE.md | ||
Cargo.toml | ||
CONTRIBUTING.md | ||
LICENSE | ||
navbar.md | ||
OWNERS | ||
PRESUBMIT.cfg | ||
README.chromeos.md | ||
README.md | ||
run_tests | ||
rust-toolchain | ||
setup_cros_cargo.sh | ||
test_all | ||
unblocked_terms.txt |
crosvm - The Chrome OS Virtual Machine Monitor
crosvm is a virtual machine monitor (VMM) based on Linux’s KVM hypervisor, with a focus on simplicity, security, and speed. crosvm is intended to run Linux guests, originally as a security boundary for running native applications on the Chrome OS platform. Compared to QEMU, crosvm doesn’t emulate architectures or real hardware, instead concentrating on paravirtualized devices, such as the virtio standard.
crosvm is currently used to run Linux/Android guests on Chrome OS devices.
- Documentation
- Announcements
- Developer Mailing List
- #crosvm on matrix.org
- Source code
- API doc, useful for searching API.
- For contribution, see the contributor guide. Mirror repository is available at GitHub for your convenience, but we don't accept bug reports or pull requests there.
- Issue tracker