Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix possible bugs when loading ELF/PVH kernel #29

Merged
merged 4 commits into from
Apr 2, 2020

Conversation

jiangliu
Copy link
Member

This series includes:

  1. a patch to exactly matching PVH entry point in ELF note section.
  2. do not assume ELF program headers are sorted ascendantly by virtual address.
  3. refine the dependency relationship to vm-memory.
    Thanks!

@sameo
Copy link
Collaborator

sameo commented Mar 24, 2020

This LGTM but I'd like to get @aljimenezb review on that one.

src/loader/mod.rs Outdated Show resolved Hide resolved
@andreeaflorescu
Copy link
Member

@jiangliu is it possible to also add unit tests for the bug fixes? I strongly encourage to have regression tests whenever we fix bugs to make sure we don't introduce them again.

Comment on lines 309 to 313
#[cfg(feature = "elf")]
#[cfg(any(target_arch = "x86", target_arch = "x86_64"))]
// Size of string "PVHNote", including the terminating NULL.
const PVH_NOTE_STR_SZ: usize = 8;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that checking for both name and type when searching for the PVH note is the right approach, for the reason @jiangliu mentions in the commit message. This will avoid any future collisions due to another namespace using type 0x12 as well.

This patch will not work correctly yet, because the name specified in the PVH ABI is actually just "Xen". So the code above must be changed to:

// Size of string "Xen", including the terminating NULL.
const PVH_NOTE_STR_SZ: usize = 4;

The unit tests I added on this commit use "PVHNote" as the name to generate the test_*note.bin binaries and they must be corrected. I can generate new binaries and share them, or they can be built using the instructions in the commit. Please let me know if you'd like me to do this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jiangliu I built new binaries that are needed to fix the unit tests. Binaries, source and instructions on how to build are here:
https://gist.github.com/aljimenezb/9918b8562070cb89ab6696025305e3f9

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the linux kernel use "Xen" and I used "Xen" too at first, but it fails the unit tests:(
I will update it in next version.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aljimenezb can you add the instructions about generating the binaries to this repository as well? It would be easier if someone else needs to generate some in the future.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@andreeaflorescu Sure, I'll open a separate PR for that change. That content feels a little bit out of place in the main README, but we can figure out the details on the discussion.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, maybe we can have a contributing document? Or development?

Another idea would be for those binaries to be generated at build time. I am not a big fun of having binaries in repositories.

Copy link
Contributor

@aljimenezb aljimenezb Mar 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another idea would be for those binaries to be generated at build time. I am not a big fun of having binaries in repositories.

That was my first instinct, but I saw test_elf.bin was already in use so I followed that simpler approach instead.

I am not familiar with the capabilities of inline assembly in Rust, so I'd like feedback from others here as to whether or not it is possible to build the assembly source code using Rust inline assembly templates.

src/loader/mod.rs Outdated Show resolved Hide resolved
Copy link
Collaborator

@rbradford rbradford left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR breaks PVH boot (the code goes back through the vmlinux) path when it was tested with Cloud Hypervisor. I recommend you put a debug statement in arch::x86_64::configure_system to print out the value of boot_proto.

@aljimenezb
Copy link
Contributor

This PR breaks PVH boot (the code goes back through the vmlinux) path when it was tested with Cloud Hypervisor. I recommend you put a debug statement in arch::x86_64::configure_system to print out the value of boot_proto.

@rbradford I am assuming you tested with the current code, and without the changes I suggested above. In that case yes, it will break PVH boot since the Linux kernel uses "Xen" as the name for the note header that encodes the PVH address.

After applying my proposed changes above, I booted successfully using the PVH path on Cloud Hypervisor. If you did the same and still found the error please let me know and I'll take another look.

@rbradford
Copy link
Collaborator

@rbradford I am assuming you tested with the current code, and without the changes I suggested above. In that case yes, it will break PVH boot since the Linux kernel uses "Xen" as the name for the note header that encodes the PVH address.

Indeed.

@sboeuf
Copy link

sboeuf commented Mar 26, 2020

@jiangliu just wanted to mention that I tried this PR yesterday, and it breaks the PVH support.

@jiangliu
Copy link
Member Author

@jiangliu just wanted to mention that I tried this PR yesterday, and it breaks the PVH support.

Yes, the patch should be updated to checking "Xen" instead of "PVHNote".
Will send out updated version soon.

Refine dependency on vm-memory crate by:
1) relax version number constraint to "0.x.y"
2) enable feature vm-memory/backend-mmap for development only because
   it's used by unit test cases.

Signed-off-by: Liu Jiang <[email protected]>
According to Linux kernel documentation:
Each note has three parts: a name, a type and a desc.  The name is
intended to distinguish the note's originator, so it would be a
company, project, subsystem, etc; it must be in a suitable form for
use in a section name.  The type is an integer which is used to tag
the data, and is considered to be within the "name" namespace (so
"FooCo"'s type 42 is distinct from "BarProj"'s type 42).  The
"desc" field is the actual data.  There are no constraints on the
desc field's contents, though typically they're fairly small.

So check both name and type when searching for the PVH note.

Signed-off-by: Liu Jiang <[email protected]>
@jiangliu jiangliu force-pushed the bugfix_v1 branch 2 times, most recently from 1a0fecb to 025db34 Compare March 28, 2020 08:56
Copy link
Contributor

@aljimenezb aljimenezb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor nits about comments and one correctness issue.

src/loader/x86_64/elf/mod.rs Outdated Show resolved Hide resolved
src/loader/x86_64/elf/mod.rs Outdated Show resolved Hide resolved
src/loader/x86_64/elf/mod.rs Outdated Show resolved Hide resolved
@josephlr
Copy link

rust-hypervisor-firmware recently added PVH support in cloud-hypervisor/rust-hypervisor-firmware#26.

I tested this patch w/ Cloud-Hypervisor, and I can confirm that this patch doesn't break anything with regards to the firmware. We can still boot via the PVH Boot protocol.

rbradford
rbradford previously approved these changes Mar 30, 2020
Copy link
Collaborator

@rbradford rbradford left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm based on @josephlr feedback

Copy link
Contributor

@aljimenezb aljimenezb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with one minor nit:
The addition of the new test ELF binaries should be moved to commit d19aea9 rather than where it is now at commit be5edd4.

Sorry I didn't catch this before. This is not a stopper, but besides keeping the logical consistency of the commits, it will preserve the ability to run git bisect without the unit tests failing.

Do not assume program header is sorted ascendantly by virtual
address, otherwise loader_result.kernel_end may be wrong.

Signed-off-by: Liu Jiang <[email protected]>
Copy link
Contributor

@aljimenezb aljimenezb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thank you @jiangliu.

@sameo sameo merged commit 43d1c51 into rust-vmm:master Apr 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants