protos/chainload: Add native_load option for efi protocol

[valiukasd]

Description:
This PR implements native UEFI firmware loading to resolve BitLocker/TPM issues found by me.

This implementation is heavily inspired by the previous PR for protocol: efi_handover, but directly addresses the maintainer's feedback by keeping the logic entirely within the existing protocol: efi to avoid code duplication and preserve backwards compatibility. Their code did not work also, just blank screen after trying to boot.

Why this is needed:

As noted by @alexvoste in #578:

Currently, the standard protocol: efi reads the target binary into a memory buffer before passing it to gBS->LoadImage(). Executing from an anonymous RAM buffer alters the TPM PCR 4 measurement because Limine leaves an active footprint in the boot process. As a result, Windows BitLocker detects a "tampered" boot path and forces the user into the recovery key screen on every dual-boot start.

What this PR does:
Instead of a completely separate protocol, this PR introduces a native_load: yes config modifier for the efi protocol.
When native_load is enabled:

1. It skips the memmap_alloc_range_in buffer allocation, without touching the RAM.
2. It introduces a new append_device_path helper function. This manually stitches the partition's device path and the relative file path together into a combined absolute hardware path (which fixes the critical crash that occurs if you try to pass a relative path directly to LoadImage).
3. It passes this stitched, raw EFI_DEVICE_PATH is passed directly to gBS->LoadImage(FALSE, ...), allowing the motherboard's native filesystem drivers to handle the loading.
4. If the flag is omitted (or set to no), it falls back to the original memory-mapped behavior, meaning features like transparent decompression remain fully intact.

Closes issue #576

Testing status:

• The project builds with no issues (I am using gcc, with the included makefile).
• It successfully fixes the TPM PCR 4 measurements, allowing working dual-booting with Windows BitLocker active without requiring double-POST reboots via efi_boot_entry.

A quick note from me:
I am quite new to this kind of low-level development, so criticism welcome! I did my best to follow the style guidelines in CONTRIBUTING.md, but since there aren't any automated formatting tools in the repo, I apologize if I formatted incorrectly. It looks like my IDE formatted to some coding style, and now the changes have blown up! Please feel free to push commits directly to my branch to fix any formatting if needed.

Also, please let me know if I need to add an entry to the ChangeLog or do any other administrative steps for this to be accepted! Thanks for your time and for maintaining such an awesome bootloader.

[alexvoste]

Hey @valiukasd, I see you opened PR #586 'Add nativeload option for efi protocol'. This PR seems to be a direct re-implementation of the feature I proposed and developed in my Draft PR #578 'efi: add protocol: efihandover for firmware-native chainloading', which you even referenced as 'previous PR for protocol: efi_handover' in your description.

While I appreciate you being 'inspired', this is effectively taking my work, which I put effort into and opened as a Draft to gather feedback and testing (as noted in my PR's 'Testing status'). My intention was to finalize and submit my #578 PR.

I believe the correct approach here would be to either: a) Close your PR #586 and let me finalize and submit my original PR #578, with proper attribution if you contributed any specific fixes/testing. Or b) Convert your PR into a collaborative effort where I am specifically acknowledged as the primary author/contributor of the core idea and initial implementation, and we merge it under a joint effort or I am properly credited. Please clarify your intentions as this feels like an unethical appropriation of my work.

[alexvoste]

To follow up on this and strictly for the project maintainers' visibility:

If you compare the descriptions of both PRs, @valiukasd has literally copy-pasted my documentation from #578 word-for-word under his "Why this is needed" section (from "Currently, the standard protocol..." down to "...recovery key screen on every dual-boot start").

Claiming that my Draft "did not work" to justify copying my research, exact architectural layout, and documentation into a brand new PR—instead of contributing the missing path-stitching helper directly to my open branch—goes entirely against open-source etiquette. It's a clear attempt to claim sole credit for someone else's active development.

cc: @Mintsuki / @Limine-Bootloader maintainers — I would deeply appreciate your guidance on how to handle this correctly so we can land this feature under proper authorship and collaborative standards.

[valiukasd]

To follow up on this and strictly for the project maintainers' visibility:

If you compare the descriptions of both PRs, @valiukasd has literally copy-pasted my documentation from #578 word-for-word under his "Why this is needed" section (from "Currently, the standard protocol..." down to "...recovery key screen on every dual-boot start").

Claiming that my Draft "did not work" to justify copying my research, exact architectural layout, and documentation into a brand new PR—instead of contributing the missing path-stitching helper directly to my open branch—goes entirely against open-source etiquette. It's a clear attempt to claim sole credit for someone else's active development.

cc: @Mintsuki / @Limine-Bootloader maintainers — I would deeply appreciate your guidance on how to handle this correctly so we can land this feature under proper authorship and collaborative standards.

Hi @alexvoste,

Sorry if I did something wrong, and sorry for the frustration caused, I did infact copy some parts of the PR description, and I have updated the description to properly attribute the research to you and link back to #578.

However, to clarify the timeline and the work for you and the maintainers:

The idea: In the original issue I opened (#576), I was the one who initially suggested using protocol: efi_handover or an alternate flag.

The code: If you look at the actual code changes, they are entirely different. This PR implements a working solution natively within the existing protocol: efi as a configuration option, explicitly incorporating the maintainer feedback from your PR. It does not use your code, nor does it use your architecture.

Trying to implement a working solution myself to learn low-level programming is well within the spirit of open source. I hope the additional attribution in the description resolves your concerns about credit so the maintainers can evaluate the actual code.

P.S Can we please keep conversations human? I apologize if you wrote the comments yourself, but to me it seems like an overly dramatic corporate lawyer response that an LLM would generate.

[alexvoste]

To follow up on this and strictly for the project maintainers' visibility:
If you compare the descriptions of both PRs, @valiukasd has literally copy-pasted my documentation from #578 word-for-word under his "Why this is needed" section (from "Currently, the standard protocol..." down to "...recovery key screen on every dual-boot start").
Claiming that my Draft "did not work" to justify copying my research, exact architectural layout, and documentation into a brand new PR—instead of contributing the missing path-stitching helper directly to my open branch—goes entirely against open-source etiquette. It's a clear attempt to claim sole credit for someone else's active development.
cc: @Mintsuki / @Limine-Bootloader maintainers — I would deeply appreciate your guidance on how to handle this correctly so we can land this feature under proper authorship and collaborative standards.

Hi @alexvoste,

Sorry if I did something wrong, and sorry for the frustration caused, I did infact copy some parts of the PR description, and I have updated the description to properly attribute the research to you and link back to #578.

However, to clarify the timeline and the work for you and the maintainers:

The idea: In the original issue I opened (#576), I was the one who initially suggested using protocol: efi_handover or an alternate flag.

The code: If you look at the actual code changes, they are entirely different. This PR implements a working solution natively within the existing protocol: efi as a configuration option, explicitly incorporating the maintainer feedback from your PR. It does not use your code, nor does it use your architecture.

Trying to implement a working solution myself to learn low-level programming is well within the spirit of open source. I hope the additional attribution in the description resolves your concerns about credit so the maintainers can evaluate the actual code.

P.S Can we please keep conversations human? I apologize if you wrote the comments yourself, but to me it seems like an overly dramatic corporate lawyer response that an LLM would generate.

valiukasd yo, listen up. I just crushed the issue that was open, right? You hit me up saying you'd test it out and get back to me. But then, you just straight up jacked my idea, dropped it with my EXACT same text, word-for-word, while my damn PR is still wide open, and you had the balls to manually copypaste it?! LMAO, dude, that's just fucked up.

And then you got the nerve to tell me I'm writing with an LLM, WTF man?! Dude, you straight-up jacked my idea, pushed it under your name, stole my documentation word-for-word, and now you're talking shit? That's just low, man. Maybe you should just stick to web development, fucking scrub. Who gives a shit about being subtle, right?

Doesn't sound like an LLM now, does it? xD

[alexvoste]

To the maintainers and for the record, especially @Mintsuki:

I find it deeply troubling that @valiukasd, a self-proclaimed 'Student, Full-Stack web developer' (see attached screenshot of his GitHub profile), has submitted a PR to a critical low-level project like Limine-Bootloader based on stolen documentation and architectural ideas (as initially detailed in my issue #578 and further elaborated in this discussion).

His latest comment on my PR (see attached screenshot) further reveals he does not yet know how to build and use the local version of the bootloader.

Submitting code to a bootloader project while still 'figuring out how to build' it, combined with plagiarism of another contributor's detailed technical write-up, is not in the spirit of open source. It poses a significant risk to the project's integrity (due to potential lack of fundamental understanding) and is a blatant disregard for intellectual contribution.

This behavior from someone 'learning low-level programming' by directly copying critical research from others, and then accusing the original author (myself) of being an LLM, is frankly unacceptable.

I urge the maintainers, particularly @Mintsuki, to review this chain of events, including the provided screenshots, and take appropriate action regarding @valiukasd's contributions and conduct.

[valiukasd]

@alexvoste

I do not know why you are trying to get personal, and what my Github profile has to do with it.

To reiterate:

I did not steal your idea, nor the architecture. I merely used your PR description as a template, since this repository does not have one. I am sorry for not changing some parts of the description, but this is why I said that this PR is heavily inspired by yours (I should not have said "inspired implementation", because it is 100% mine). Pleaese check the patch and see that the code is nothing like yours.

If you are so offended about the PR description, you are free to take my patch and submit instead of your non-working AI generated code (I can tell by the comments). So how is a web developer submitting better code than a 'low-level' professional?

Either way, I do not care about attribution, I just want my bootloader to work.

And one more thing, please reply as yourself, I again, feel like I am talking to an LLM, unless you as an actual human being bold your last sentence just to make it "that ultimate burn" (calling me a fucking scrub was unnecessary). Please try to keep it civil.

P.S I am pretty sure that direct personal insults like these directly violate Github's own Terms of Service and Code of Conduct, so I will be reporting this to Github directly.

[iczelia]

Dear @alexvoste, @valiukasd

The chief maintainer is taking a longer break from Github for personal reasons. I have been designated as their interim replacement.

Thank you for your contributions (the tickets and the merge requests). Let me attempt to clear some misunderstandings.

To Deividas: If your work was based on previous PRs and reviews, this should have been disclosed from the start. Also your merge requests should always explicitly and clearly state the testing status.

Ultimately I am not sure if this feature will be merged in the first place because of Mint's previous objections. Have you tested the interactions of your implementation with hashing (#) and transparent (de)compression ($)? I will give it a try later myself too.

To Alex: Responding to your objection; I believe Karl Fogel, Producing Open Source Software to be a pretty good source of guidance in how to contribute to open source and how to run open source projects. I highly recommend both of you to read it. The book describes the situation that has arosen as "Cookie Licking" in Chapter 8, "Managing Participants." In principle, anyone is free to re-implement the functionality asked for by the ticket #576 and there is nothing wrong with having multiple competing implementations. Opening a pull request two weeks ago that was scope-rejected after one round of review does not entitle you to being able to forever be the only person to ever touch the ticket or the code. Personally, I see no copied documentation (the previous one had none to begin with) and no particular similarity structure-wise between the two merge requests. Hence to me they personally stand out as of independent lineage.

Responding to your messages made towards Deividas: To me, this is grounds for immediate and long-term ban from contributing to the project, and you can expect the same action from virtually any other maintainer. Since I am not the owner of the repository and cannot take such decisions autonomously, you will be given one more chance to engage in civil discussions; your failure to comply will cause the main maintainer to come back briefly for the sole reason of blocking you.

[valiukasd]

Thank you for your reply @iczelia , I will update to add the testing status on my new open PR, I decided to close this one on the grounds of it having too much unrelated chatter. I will try to test hashing and compression if I am able to, but I have not yet setup easy testing, I build the bootloader every time there is a change, so it would be ideal if you could test it and provide feedback if there are any errors, I will go from there. I do not fully understand the compression and hashing. Or if it does not work, maybe we can mention in the docs that this change does not work with compression or hashing, because this is a niche feature for a specific fix (Bitlocker), so if by default it breaks nothing, then perhaps it can still be merged? I don't know if windows efi can be compressed or hashed either way, and I doubt that many people do that

To Deividas: If your work was based on previous PRs and reviews, this should have been disclosed
from the start. Also your merge requests should always explicitly and clearly state the testing
status.

I have specified in the original PR that my PR is inspired by the tagged PR only in the description template and comments on it. I mentioned that the "implementation" was inspired by mistake. I think that is why Alex or his LLM got confused, even though the code or architecture is not similar at all. This is the cause of the confusion.