Sou usuário de desktop linux e sempre usei o Secure Boot. Qual a opinião de vocês? É necessário apenas para usuários corporativos?
1 curtida
Desnecessário beirando ao inútil.
3 curtidas
Teoricamente pode te proteger de um ataque com algum rootkit que atinja o boot, mas realisticamente falando acho isso pouco provável em computadores caseiros. Talvez com essas doideiras agora de IA descobrindo brecha de segurança a parada tome rumos diferentes. Eu deixo ligado mas pra mim na verdade não faz diferença, se me encher o saco eu simplesmente desativo.
1 curtida
Cara é uma camada de proteção a mais, mas considerando que é fina e que já existem vírus e hacker que aprenderam a burla-lo é praticamente inútil, mas quem quiser ter uma proteção a mais, não custa nada habilitar…
1 curtida
Eu deixo habilitado.Essa parte do lado esquerdo ainda não consegui resolver, mas pelo que pesquisei, meu hardware não tem suporte.
1 curtida
@Auder Qual é a sua distro? Às vezes é porque está faltando instalar algum pacote.
Debian…instalei normal, inclusive repositórios non-free.
Aqui não uso mais.
Eu já tive esse problema antes no openSUSE, e inclusive agora mesmo estava desse jeito (havia reinstalado o sistema dias atrás e ainda não tinha parado pra “arrumar” isso):
Após reinstalar o pacote tpm2.0-tools resolveu:
Acredito que no Debian o nome do pacote seja tpm2-tools, então só rodar um sudo apt install tpm2-tools e ver se resolve.
Como pode ver, as verificações básicas passaram. No meu caso ainda está reclamando que não foi possível verificar o Linux kernel, mas acho que aí já não tem muito o que fazer, estou usando o kernel-longterm do repositório oficial no openSUSE Tumbleweed/Slowroll. O kernel-default também acontece a mesma coisa. Então simplesmente ignoro isso; a chance de ter algo malicioso no kernel fornecido pela própria distro é ridícula.
1 curtida
@Thiago12 @Auder
Para saber as informações com mais detalhes:
sudo fwupdmgr security
Caso não tiver instalado o pacote é fwupd ou algo assim.
Exemplo da minha saída:
WARNING: UEFI capsule updates not available or enabled in firmware setup
See https://github.com/fwupd/fwupd/wiki/PluginFlag:capsules-unsupported for more information.
Host Security ID: HSI:0! (v2.0.8)
HSI-1
✔ Fused platform: Locked
✔ Supported CPU: Valid
✔ TPM empty PCRs: Valid
✔ TPM v2.0: Found
✔ UEFI bootservice variables: Locked
✔ UEFI platform key: Valid
✘ BIOS firmware updates: Disabled
HSI-2
✔ IOMMU: Enabled
✔ Platform debugging: Locked
✔ TPM PCR0 reconstruction: Valid
✘ SPI write protection: Disabled
HSI-3
✔ CET Platform: Supported
✘ SPI replay protection: Not supported
✘ Pre-boot DMA protection: Disabled
✘ Suspend-to-idle: Disabled
✘ Suspend-to-ram: Enabled
HSI-4
✔ SMAP: Enabled
✘ Processor rollback protection: Disabled
✘ Encrypted RAM: Not supported
Runtime Suffix -!
✔ fwupd plugins: Untainted
✔ Linux swap: Disabled
✔ Linux kernel: Untainted
✔ UEFI db: Valid
✘ CET OS Support: Not supported
✘ Linux kernel lockdown: Disabled
✘ UEFI secure boot: Disabled
This system has a low HSI security level.
» https://fwupd.github.io/hsi.html#low-security-level
This system has HSI runtime issues.
» https://fwupd.github.io/hsi.html#hsi-runtime-suffix
Upload these anonymous results to the Linux Vendor Firmware Service to help other users? [y|N]: n
2 curtidas
Valeu, vou verificar .
1 curtida
Beleza, vou ver
Pelo pouco que consegui entender, esse “secure boot” depende de uns arquivos “shim” – “assinados pela Microsoft” – ou de algo ainda mais chato, que eu teria de providenciar manualmente, nem sei como, nem onde:
Lembrando que eu não tenho Windows, nem pretendo ter.
Ora, eu só tenho arquivos “shim” do openSUSE, Fedora, Debian e MX Linux:
# tree -U -D --timefmt ' %F %T ' /boot/efi # tree -U -D --timefmt ' %F %T ' /mnt
[ 1969-12-31 21:00:00 ] /boot/efi [ 1969-12-31 21:00:00 ] /mnt
├── [ 2026-04-26 17:33:12 ] EFI ├── [ 2026-04-26 17:56:44 ] EFI
│ ├── [ 2020-01-10 17:22:00 ] pclinuxos │ ├── [ 2026-01-24 13:46:28 ] Mx25_grub
│ │ └── [ 2026-03-02 21:17:24 ] grubx64.efi │ │ ├── [ 2026-01-24 13:46:28 ] shimx64.efi
│ ├── [ 2025-07-22 21:00:00 ] boot │ │ ├── [ 2026-01-24 13:46:28 ] grubx64.efi
│ │ ├── [ 2025-07-13 22:20:42 ] bootx64.efi │ │ ├── [ 2026-01-24 13:46:28 ] mmx64.efi
│ │ ├── [ 2020-01-11 14:09:28 ] fallback.efi │ │ ├── [ 2026-01-24 13:46:28 ] fbx64.efi
│ │ ├── [ 2025-07-13 22:20:42 ] fbx64.efi │ │ ├── [ 2026-01-24 13:46:28 ] BOOTX64.CSV
│ │ ├── [ 2025-07-13 22:20:42 ] mmx64.efi │ │ └── [ 2026-01-24 13:46:28 ] grub.cfg
│ │ ├── [ 2024-03-18 21:00:00 ] BOOTIA32.EFI │ ├── [ 2025-04-08 22:29:12 ] Mageia_grub
│ │ └── [ 2024-03-18 21:00:00 ] fbia32.efi │ │ └── [ 2025-04-08 22:29:12 ] grubx64.efi
│ ├── [ 2020-01-12 22:39:12 ] opensuse │ ├── [ 2025-04-08 22:59:52 ] Void_grub
│ │ ├── [ 2020-09-24 23:23:16 ] MokManager.efi │ │ └── [ 2025-04-08 22:59:52 ] grubx64.efi
│ │ ├── [ 2020-09-24 23:23:16 ] grub.efi │ ├── [ 2025-07-13 18:06:58 ] BOOT
│ │ ├── [ 2020-09-24 23:23:16 ] shim.efi │ │ ├── [ 2025-07-16 13:26:38 ] mmx64.efi
│ │ ├── [ 2020-09-24 23:23:16 ] boot.csv │ │ ├── [ 2025-04-21 18:08:02 ] BOOTIA32.EFI
│ │ ├── [ 2020-09-24 23:23:16 ] grub.cfg │ │ ├── [ 2026-04-07 14:26:04 ] BOOTX64.EFI
│ │ ├── [ 2026-04-26 16:16:38 ] grubx64.efi │ │ ├── [ 2025-04-21 18:08:02 ] fbia32.efi
│ │ ├── [ 2020-01-12 22:39:12 ] fw │ │ └── [ 2025-07-16 13:26:38 ] fbx64.efi
│ │ └── [ 2020-09-02 14:55:36 ] fwupdx64.efi │ └── [ 2026-04-07 14:26:04 ] Artix
│ ├── [ 2026-04-12 12:32:16 ] fedora │ └── [ 2026-04-07 14:26:04 ] grubx64.efi
│ │ ├── [ 2024-03-18 21:00:00 ] BOOTIA32.CSV ├── [ 2025-04-21 18:08:02 ] System
│ │ ├── [ 2024-03-18 21:00:00 ] BOOTX64.CSV │ └── [ 2025-04-21 18:08:02 ] Library
│ │ ├── [ 2026-04-07 21:00:00 ] gcdia32.efi │ └── [ 2025-04-21 18:08:04 ] CoreServices
│ │ ├── [ 2026-04-07 21:00:00 ] gcdx64.efi │ └── [ 2025-04-21 18:08:04 ] SystemVersion.plist
│ │ ├── [ 2026-04-07 21:00:00 ] grubia32.efi ├── [ 2024-04-10 18:35:34 ] System Volume Information
│ │ ├── [ 2026-04-07 21:00:00 ] grubx64.efi └── [ 2025-04-21 18:08:02 ] mach_kernel
│ │ ├── [ 2024-03-18 21:00:00 ] mmia32.efi
│ │ ├── [ 2024-03-18 21:00:00 ] mmx64.efi 11 directories, 16 files
│ │ ├── [ 2024-03-18 21:00:00 ] shim.efi
│ │ ├── [ 2020-01-12 12:47:36 ] grub.cfg.rpmsave
│ │ ├── [ 2024-03-18 21:00:00 ] shimia32.efi
│ │ ├── [ 2021-07-11 11:59:08 ] grubenv.rpmsave
│ │ ├── [ 2024-03-18 21:00:00 ] shimx64.efi
│ │ └── [ 2024-11-17 14:00:52 ] grub.cfg
│ ├── [ 2020-03-24 08:01:04 ] Debian
│ │ ├── [ 2026-04-20 17:05:16 ] shimx64.efi
│ │ ├── [ 2026-04-20 17:05:16 ] grubx64.efi
│ │ ├── [ 2026-04-20 17:05:16 ] mmx64.efi
│ │ ├── [ 2026-04-20 17:05:16 ] fbx64.efi
│ │ ├── [ 2026-04-20 17:05:16 ] BOOTX64.CSV
│ │ └── [ 2026-04-20 17:05:16 ] grub.cfg
│ └── [ 2023-03-06 15:38:36 ] arch_grub2
│ └── [ 2023-03-06 15:38:36 ] grubx64.efi
├── [ 2025-07-23 21:00:00 ] System
│ └── [ 2025-07-23 21:00:00 ] Library
│ └── [ 2025-12-23 07:51:04 ] CoreServices
│ └── [ 2025-07-23 21:00:00 ] SystemVersion.plist
├── [ 2024-04-10 18:35:34 ] System Volume Information
└── [ 2025-07-23 21:00:00 ] mach_kernel
13 directories, 37 files
Mas isso, é o pouco que eu (acho que) entendi até agora.
Quando eu comecei a lidar com UEFI pela primeira vez, em 2020, a única coisa que eu tinha entendido, era: – “Desative o Secure Boot pra conseguir dar boot em distros Linux”.
Eu deixo esse treco desligado.
1 curtida
Instalei o TPM2-tools, mas nada mudou.Vou seguir levando tá funcionando redondinho. Não sei se é “memória falsa”, mas eu me lembro dos 2 estarem “verdinhos”, faz algum tempo.
Prezados, eu tenho uma dúvida a respeito disso.
Para contextualizar, atualmente secureboot está desativado, porém alguns jogos no windows exigem que esteja ativo para funcionar.
Meus sistemas estão em drives distintos, e no caso do windows inclusive desmontei o driver, para que o sistema não enxergue de maneira alguma o volume com o linux. Outro detalhe, eu utilizo do rEFInd para gerenciar os boots.
Dito isso, em que implica a ativação do secureboot? Eu posso ter algum problema de compatibilidade com meu sistema? Preciso realizar alguma alteração relevante?
É nesse caso, ou falta habilitar o TPM 2.0 nas configurações da placa-mãe ou a sua placa-mãe não tem suporte mesmo.
1 curtida
Até tem. Eu entrei na BIOS, desabilitei o tpm, desabilite fast boot e também o secureboot. Reiniciei .., depois habitei novamente (exceto o fastboot). e aí o tpm e o kernela pareceram ticados como o seu aí em cima no post., mas continua como antes. Desencanei, ta funcionando , caso precise de uma reinstalação no futuro ai vou de padrão pra ver qual é. Valeu por responder.
1 curtida