Adding sbctl to the ISO to better support Secure Boot #189

Closed
opened 2025-03-30 08:40:38 +00:00 by fhdk · 5 comments
fhdk commented 2025-03-30 08:40:38 +00:00 (Migrated from gitlab2.manjaro.org)

I have written about Secure Boot on the forum - why it is not supported OOB due to not having a public key to verify a signed loader.

I have also written a proof-of-concept topic about utilising Secure Boot on existing dual-boot systems where company policy demands Secure Boot enabled - Microsoft Lynx will not work without an active Secure boot setting.

I am thinking of writing yet another guide to support setting up Secure Boot at install time.

This will require the sbctl package already present on the installed system - thus included within our iso-profiles - preferably in the Packages-Root file.

What is your thoughts on this?

@all

I have written about Secure Boot on the forum - why it is not supported OOB due to not having a public key to verify a signed loader. I have also written a proof-of-concept topic about utilising Secure Boot on existing dual-boot systems where company policy demands Secure Boot enabled - Microsoft Lynx will not work without an active Secure boot setting. I am thinking of writing yet another guide to support setting up Secure Boot at install time. This will require the **sbctl** package already present on the installed system - thus included within our iso-profiles - preferably in the Packages-Root file. What is your thoughts on this? @all
dennis1248 commented 2025-03-30 09:55:42 +00:00 (Migrated from gitlab2.manjaro.org)

I had requested Phil to do some research on Secure Boot and how it can be implemented in Manjaro. I had found a potential source of funding should we opt to get our keys signed by Microsoft, the benefit of this route is that they will just work and do not require the user to first disable Secure Boot.

I had requested Phil to do some research on Secure Boot and how it can be implemented in Manjaro. I had found a potential source of funding should we opt to get our keys signed by Microsoft, the benefit of this route is that they will just work and do not require the user to first disable Secure Boot.
fhdk commented 2025-03-30 10:13:32 +00:00 (Migrated from gitlab2.manjaro.org)

If using Microsoft we create a dependency on Microsoft and while this can simplify some aspects we should rather support Secure Boot as a unique key on the end user's system.

When the funding dries out? What then? I think it is better to stay independent of Microsoft in this matter.

From a security perspective - it is also better the key to sign the unified kernel is generated locally using sbctl and unknown in a broader perspective.

From a security perspective we also raise awareness on the topic of securing the firmware from third party malicious modifications.

The way Microsoft delivers the system - either through branded hardware or using vendors is a necessary method - they provide insecure systems - leaving it up to the end user's to educate themselves on their device security.

Manjaro Linux should stand out in that regard by enforcing the user to make deliberate choice with regards to device security.

If using Microsoft we create a dependency on Microsoft and while this can simplify some aspects we should rather support Secure Boot as a unique key on the end user's system. When the funding dries out? What then? I think it is better to stay independent of Microsoft in this matter. From a security perspective - it is also better the key to sign the unified kernel is generated locally using sbctl and unknown in a broader perspective. From a security perspective we also raise awareness on the topic of securing the firmware from third party malicious modifications. The way Microsoft delivers the system - either through branded hardware or using vendors is a necessary method - they provide insecure systems - leaving it up to the end user's to educate themselves on their device security. Manjaro Linux should stand out in that regard by enforcing the user to make deliberate choice with regards to device security.
fhdk commented 2025-03-30 10:53:48 +00:00 (Migrated from gitlab2.manjaro.org)

the benefit of this route is that they will just work and do not require the user to first disable Secure Boot

That got me thinking more ...

Going down such route will make maintenance of Manjaro Linux as distribution much more complicated.

This topic is for the community - I do not have and will not have anything to do with the company part.

The community is not served well with a dependency on Microsoft - what the company Manjaro will do is not relevant in this topic.

I am simply asking for the inclusion of sbctl so a community member is better equipped to be able to implement Secure Boot - if so desired.

Manjaro Community should never be left to the mercy of Microsoft to be able to implement Secure Boot using sbctl.

> the benefit of this route is that they will just work and do not require the user to first disable Secure Boot That got me thinking more ... Going down such route will make maintenance of Manjaro Linux as distribution much more complicated. This topic is for the community - I do not have and will not have anything to do with the company part. The community is not served well with a dependency on Microsoft - what the company Manjaro will do is not relevant in this topic. I am simply asking for the inclusion of **sbctl** so a community member is better equipped to be able to implement Secure Boot - if so desired. Manjaro Community should never be left to the mercy of Microsoft to be able to implement Secure Boot using sbctl.
fhdk commented 2025-03-30 14:25:27 +00:00 (Migrated from gitlab2.manjaro.org)

mentioned in merge request !387

mentioned in merge request !387
fhdk commented 2025-03-30 14:28:25 +00:00 (Migrated from gitlab2.manjaro.org)

Closed with !387

Closed with !387
fhdk (Migrated from gitlab2.manjaro.org) closed this issue 2025-03-30 14:28:26 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
profiles/iso-profiles#189
No description provided.