-
Notifications
You must be signed in to change notification settings - Fork 46
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
UEFI status #260
Comments
UEFI was never support and there are no plans to support it in scope of coreboot maintainership services package which 3mdeb provide to PC Engines. If you need that support you may inquiry PC Engines or hack it yourself - contribution is welcome. We getting inquiries about UEFI and Secure Boot support for PC Engines, but we address that as part of our Dasharo product lines.
Yes, and it may have its own issues related to toolchain comaptibility and completnes of feature set exposed and support in UEFI.
I doubt if Secure Boot is enabled by default - that may be the reason.
I assume problem is that there is no code that can handle saving to NVRAM.
It depends how you define "work fully", can you explain your use case? |
I had seen several videos and documents from 2017 about pcengines (or was it you?) getting UEFI working on the APU2. So I 'assumed' it was a supported concept. Our use case is using TPM to store crypttab encryption secrets. And in order to secure that, it means only allowing images signed by us to be booted on the platform. Also, is Dasharo an actual shipping product or something for the future. Few details on that website other than 'request a quote'. Thanks |
I assume you mean European coreboot Conference 2017 - coreboot and ecosystem around change a lot since that time. We detected and fixed quite a lot of bugs to make UEFI work better. UEFI on PC Engines is supported, but as commercial line of Dasharo not as part of PC Engines paid service. Please note it was not full UEFI from reset vector to operating system, this was UEFI Payload.
UEFI Secure Boot by itself doesn't make much sense, unless you dealing with some weird threat model. Even if you sign images, but you will not have some Static Root of Trust (eg. Intel Boot Guard, AMD Hardware Validated Boot etc.), then someone can replace or modify firmware and it would not detected malicious code. We fixed that using special SPI chip and locking initial part of coreboot in parallel enabling Verified Boot (through vboot) and Secure Boot - in that way platform is reasonably secure. There are also other ways to achieve that like Dynamic Root of Trust like TrenchBoot. About both things you can see research papers SRT DRT from OSFC2019. There are even more problem to security of UEFI Secure Boot eg. revocation lists maintenance.
This is product that we already shipping and maintaining pay-as-you-go model. Website and documentation would be improved as soon as we will clean our backlog. Feel free to book a call with us: https://calendly.com/3mdeb/consulting-remote-meeting |
I tried following the doc, and it appears that the current github repo that the config points to no longer has a coreboot-4.7.x-uefi branch. I'm not sure if the github repo in the config is wrong or if the repo is correct and the branch got removed :(. |
I tried with latest tianocore and it kinds of work well, i could boot pfsense in UEFI with coreboot 4.17.0.1
|
@bn82 thank you for test report. |
IT's not building anymore for 4.7.0.2, it stops for logo. It seems to be linked to this commit : coreboot/coreboot@108e537
|
There is a lot of movement around Tianocore payload recently. Additionally, we do not actively maintain Tianocore payload support for PC Engines platforms, so the build may break at any time actually. Moreover origin/master is subject to change pretty often so if you look at stable builds I would recommend fixed commit hashes |
Hello, this is ok for me, this was more for information. |
Ahh right. It uses |
This seems to be the most active thread on the UEFI topic. Just following https://github.com/pcengines/apu2-documentation/blob/master/docs/tianocore_build.md did not work for me. The pce-fw-builder misses the convert command. To add it, I changed the Dockerfile and rebuilt the OCI image. git diff Dockerfile
diff --git a/Dockerfile b/Dockerfile
index f489421..9312fed 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -2,5 +2,5 @@ FROM coreboot/coreboot-sdk:2021-04-06_7014f8258e
MAINTAINER Piotr Król <[email protected]>
USER root
COPY ./scripts/entrypoint.sh /entrypoint.sh
-RUN chmod +x /entrypoint.sh
+RUN apt-get -qq update && apt-get -y install graphicsmagick-imagemagick-compat && chmod +x /entrypoint.sh Rebuilding the container: docker build -t pcengines/pce-fw-builder -f Dockerfile . Use the new container: SDK_VER=latest
export SDK_VER With 4.17.0.3 the menuconfig looks different, but this configuration worked for me:
|
We regret to inform you that PC Engines has discontinued its sponsorship of open-source firmware. #319 |
What is the status of UEFI in the latest firmware?
I followed the instructions to build the latest v4.13.0.5 with UEFI payload. The instructions indicate to use a payload of tianocore origin/coreboot-4.7.x-uefi - does that indicate a very old version?
In device manager it shows an empty device list - where are the options to manipulate the Secure Boot platform keys, etc?
I tried to use Linux based 'efibootmgr' to add a boot item, but it didn't seem like the changes were saved to NVRAM properly. Is NVRAM working? I could not even force booting from a hard disk only.
Does this work fully with TPM2.0 module (the one it appears pcengines makes, but it has disappeared from their website)?
The text was updated successfully, but these errors were encountered: