TencentOS Linux 3 shim-15.8 x64, ia32 and aarch64 #440
Comments
steve-mcintyre
added
the
contact verification pending
|
Contact verification mails sent |
I got: secures spunkier vasectomies indecipherable uprisings shipboard Nescafe foxtrotting flawed defrays |
|
I got: unhurt recant proxies impeaching uniformed credence kickier Yemenis crates generate |
This is intended to be a tag rather than a branch. |
|
For your CA certificate: This certificate has no X.509v3 extensions. I don't know if I've ever seen that before. At a minimum I'd expect to see the |
Issues/questions:
|
|
hi, @dbnicholson thanks for your review! and we have made some adjustments for your suggestions.
Since we updated our efi files, could you please help us refresh you review? Thanks a lot! |
steve-mcintyre
added
contacts verified OK
|
All contacts verified successfully |
|
CA certificate looks more like what I'd expect now: That matches the certificate embedded in the shim |
This all looks good from my perspective 👍 |
|
Had to change the docker to amd64 from x64, I don't understand why. Ironically enough, qemu handled the arm one without asking. I was able to reproduce all three efis. All good for me! |
|
@steve-mcintyre Hi, could you help review this? Thanks! |
|
While I am not an official reviewer, looking at latest tag:
The review is still going on. To be continued |
steve-mcintyre
added
1 review needed
|
While an attempt to review TencentOS grub and kernel packages I discovered a repository containing multiple grub2 release packages (and others as well) at the same time. https://mirrors.tencent.com/tlinux/3.3/BaseOS/x86_64/os/Packages/ @costinchen, @PrinterFranklin, would you please comment on how certain version of grub2 is chosen and delivered to an OS image (and therefore other potentially vulnerable versions are prevented to get into an image)? Also a link to packages' SRPMS would be highly appreciated. |
grub.rh entry contains version and release of Tencent OS 3 (2.02-156.tl3.1), but not an original RH release. While this doesn't affect SBAT revocation function it could be misleading for a maintainer in future. |
|
Hi, @realnickel Thanks for your review and suggestion, and we have fixed the SBAT for grub2. We retained the original Red Hat release information in grub.rh and completed the release information for TencentOS 3. Now it looks like: |
Hi, @realnickel Thank you for your review. This repository contains all the grub2 packages TencentOS has ever released in the history. The new OS image will always choose the newest grub2 package so that no potentially vulnerable versions will be integrated. The users who use the older versions of image will receive a security advisory to update to newer versions of grub2. Here is the SRPMS link: grub2-2.02-158.tl3.ap.1.src.rpm |
|
Unfortunately, SRPMS link gives me |
|
@realnickel Sorry, our SRPM repository is set to be invisible externally, so it cannot be retrieved from the mirror source directly. However, our SRPMs for TencentOS 3 are basically origined from RHEL. For grub2, we based it on RHEL's grub2-2.02-158.el8 with original patches, only modifying the SBAT, release information, and the efi signing process. You can refer directly to RHEL, or I’ve added it to our repo, which you can see here: grub2-2.02-158.tl3.ap.1.src.rpm |
|
@aronowski Hi, sorry to bother you. Could you please help review this? It has been a long time since we submitted, but we haven't had an accredited reviewer to review it. Thanks a lot! |
|
Review as per As far as I understand, this is a RHEL8 fork, with a custom kernel (version 5.4 with custom patches). The application looks alright, and the binaries are reproducible. I'd just like to make sure that you indeed do have the required security patches, as 2 of the 3 upstream commits, about which the application template asks, have been introduced in newer upstream kernel versions. Do you have them backported or mitigated with a different method (this happened historically for RHEL9-based systems)? Is there a chance for the kernel SRPM to also become available, just like the GRUB2 one? |
|
@aronowski Hi, thanks for your review! Sorry, we are unable to provide the kernel SRPM as it contains source codes of kernel features developed for TencentOS, such as memory savings and performance optimizations. These features are proprietary and not publicly disclosed. Thank you for your understanding.
|
|
Looks alright! Accepting. Just a nitpick: next time instead of posting screenshots with text, just post the text itself, surrounded by three backticks (```). |
aronowski
added
accepted
|
@aronowski Hi, sorry to bother you. We have a question when requesting Microsoft's UEFI signing service. They ask for a
Did I make a mistake? What should the correct steps be? |
|
@steve-mcintyre @dbnicholson @es-fabricemarie
Could you please help us out and tell us how to properly create the Thanks to everyone who is willing to provide advice and assistance。 |
|
Are you sure you submitted to the right place? Sounds like you submitted for Driver Signing instead you need to make sure you submit for UEFI. I placed my .efi shim in the root of the cab without any other files. |
|
@es-fabricemarie Thanks for you reply. We submitted to the file signing service in Microsoft partner hardware dashboard. Is is incorrect? |
|
Yes that looks correct. |
|
We used MakeCab on windows and lcab on linux, but they all get errors. |
|
It's hard to say. Per the requirements, you're definitely supposed to have the EFI programs at the root of the CAB file. When I last did this I used gcab and generated my initial CAB file with I don't know what that screenshot is showing. For signing the CAB file, we actually use a service called SignPath, which seemed to be able to make a valid Authenticode signature. Our completed CAB file is here. You could try a single EFI program in a CAB file first. Maybe you should send an email to [email protected] for help. |
|
@dbnicholson Thank you very much for your detailed response. We’ve confirmed that the issue was with the EV certificate signing process. The colleague responsible complicated the signing steps by applying for driver information after the EV signature, which mistakenly led Microsoft to identify it as a Windows driver. |
Confirm the following are included in your repo, checking each box:
What is the link to your tag in a repo cloned from rhboot/shim-review?
https://github.com/costinchen/shim-review/tree/tencentos-3-shim-15.8-ia32-x86_64-aarch64-20250208
What is the SHA256 hash of your final SHIM binary?
What is the link to your previous shim review request (if any, otherwise N/A)?
N/A, this is our first application.
If no security contacts have changed since verification, what is the link to your request, where they've been verified (if any, otherwise N/A)?
N/A, this is our first application.
The text was updated successfully, but these errors were encountered: