리눅스 사용자, 마이크로소프트 Secure Boot에 시달려…해결책은?
출처: ZDNet
SEAN GLADWELL/Moment via Getty* ZDNET 팔로우: [우리 사이트를 선호하는 원본으로 추가]
ZDNET의 핵심 요점
- 리눅스에 새로운 Secure Boot 문제가 있습니다.
- 하지만 실제로는 일부 사람들이 생각하는만큼 심각하지 않습니다.
- 다음은 이 문제를 해결하기 위해 할 수 있는 일입니다.
2000년대 후반, 컴퓨터 펌웨어는 레거시 BIOS에서 UEFI (Unified Extensible Firmware Interface) 로 이동하고 있었습니다. 이와 동시에 Secure Boot가 등장했습니다. 이 Microsoft 지원 보안 메커니즘은 부트킷과 펌웨어 수준의 악성코드가 전통적인 운영 체제 보안으로 감지하기 어려운 단계에서 차단하도록 설계되었습니다. Secure Boot는 복잡했지만 그 역할을 수행했습니다. Windows PC에 Linux를 설치하고 실행하려는 사람들에게 이 설정은 큰 골칫점이었습니다.
이제는 Windows 8 PC에 Secure Boot가 처음 등장한 지 14년이 지나, 다시 한 번 리눅스 사용자들에게 큰 골칫점이 될 가능성이 있습니다.
다시 한 번, 일부 리눅스 애호가들은 “Microsoft가 Linux를 차단하고 있다!”라고 panic에 빠집니다. 그러나 실제로는 그렇지 않습니다. Microsoft는 “Secure Boot 인증서에는 항상 만료 날짜가 있습니다.”이라고 지적했습니다. 네, 그렇습니다. Ed Bott가 최근에 언급했듯이, Windows 사용자에게는 상당히 불편하지 않지만 일부 사람들은 만료되는 Secure Boot 인증서로 어려움을 겪을 수 있습니다.
좋은 소식은 이 걱정이 리눅스에게 종말적인 재앙이 아니라는 것입니다. 기존 시스템은 날짜가 바뀐다고 해서 갑자기 부팅을 거부하지 않습니다. 하지만 이는 Secure Boot를 지난 10년 이상 어떻게 처리했는지에 대한 진실의 순간이며, Microsoft와 OEM이 영원히 전원을 켜두길 조용히 기대하기보다는 사용자가 더 많은 통제를 취할 기회를 제공합니다.
또한: 저는 다시 최상의 macOS 대안으로 Linux를 테스트했으며, 이제는 Liquid Glass도 모방한다는 것을 확인했습니다
이제 실제로는 어떤 일이 발생하고 있는지, 왜 리눅스가 관련이 있는지, 그리고 2026년 이후에 무엇을 해야 하는지 살펴보겠습니다.
An old compromise comes due
이유를 이해하려면 2011~2012년 시기로 거슬러 올라가야 합니다. 그때 UEFI Secure Boot가 대량 시장 PC에 처음 등장했습니다. 설계 목표는 합리적이었습니다: 부팅 단계에서 운영 체제 이전에 신뢰할 수 없는 코드가 실행되지 않도록 펌웨어가 부트로더, 커널, 옵션 ROM의 서명을 확인하도록 하는 것이죠.
실제로는 Microsoft가 거의 모든 소비자 PC의 신뢰 루트를 정의했습니다. Secure Boot 키와 인증서를 만들고 사용자를 만들라는 대신, 대부분의 하드웨어 벤더는 펌웨어에 포함된 키와 인증서 집합을 배포했습니다. 이 키와 인증서는 “Microsoft 3rd‑party UEFI CA” 로, 서드파티 부트로더를 서명할 수 있었습니다. 이러한 시스템에서 사용자가 특수한 펌웨어 스위치를 조정하지 않고도 단순히 부팅하고 싶다면 배포 옵션은 두 가지였습니다:
- 사용자에게 Secure Boot를 비활화하도록 안내하는 지침을 제공합니다.
- 아니면 동참하여 Microsoft의 UEFI CA에 서명된 작은 1단계 부트로더(Shim)를 얻습니다.
대다수 주요 리눅스 배포판은 Shim을 선택했습니다. Matthew Garrett(잘 알려진 리눅스 프로그래머)이Shim 접근 방식을 만들었습니다, 이 방법은 현재도 계속 사용되고 있습니다.
이 접근 방식은 실용적인 타협이었습니다. Microsoft는 Shim을 검증하고, Shim은 리눅스 부팅 체인의 나머지를 검증하며, 사용자는 UEFI 키 데이터베이스를 직접 편집하거나 보안 기능을 비활화할 필요가 없습니다.
또한: 윈도우 서브시스템 for Linux가 개발자에게 마이크로소프트를 계속 사용하게 하는 매력적인 이유를 제공합니다 - 그 이유는 다음과 같습니다
이 타협은 매우 잘 작동했습니다. 10년 이상 동안 무작위 노트북을 구매하고 Secure Boot를 켜고 Fedora, Ubuntu, openSUSE, Debian, RHEL 등 다양한 배포판을 부팅할 수 있었습니다. 이는 펌웨어에 저장된 Microsoft 키와 EFI 시스템 파티션 내의 Microsoft 서명 Shim 바이너리 덕분이었습니다.
하지만 인증서는 타협과 달리 유효기간이 있습니다.
What’s expiring in 2026?
오늘날의 드라마 원인은 2011년 이후 Microsoft가 Secure Boot 구성 요소를 서명하기 위해 사용해 온 인증서들이 공식적인 유효 기간이 끝나가고 있다는 사실에 있습니다. 몇 개의 2011년식 Microsoft Secure Boot 인증서는 2026년에 두 차례의 주요 물결(연초와 연말)에 걸쳐 수명을 마치게 됩니다.
이 문제를 해결하기 위해 Microsoft는 2023년에 새로운 Secure Boot 인증서 집합을 만들고 OEM 및 플랫폼에 배포했습니다. 펌웨어 업데이트는 새 키를 추가하고, 구旧 인증을 유지하며, 향후 부팅 구성 요소가 검증될 수 있도록 하는 조용한 작업을 수행하도록 설계되었습니다.
또한: Microsoft가 Build 2026에서 대규모 리눅스 추진을 계속하고 있다
Windows 전용 업체에겐 이는 대부분 자동 패치 작업입니다. 반면 리눅스 세계에서는 상황이 다릅니다,
사람들이 “인증서 만료”라는 말을 들으면 SSL 인증서와 유사하게 생각합니다. 그 날짜가 “notAfter”를 넘으면 클라이언트가 서버와 통신 refusing 합니다. 이러한 mental model은 2026년을 절벽 같은 경계로 만들며, 6월 24일이 찾아오면 갑자기 배포판이 부팅되지 않게 됩니다.
Secure Boot는 그렇게 작동하지 않습니다. 현재 펌웨어가 2011년 Microsoft UEFI CA를 신뢰하고 있다면, 캘린더가 만료 기간으로 넘어가더라도 거의 확실히 계속 신뢰할 것입니다. 기존 Linux 설치와 그 기존 Shim 및 부트로더는 언제나 그랬듯 부팅을 계속합니다. 자정 사이에 마법처럼 브릭될 일도 없습니다.
Here’s the problem
문제는 현재 부팅이 아니라 미래 부팅에 있습니다. 오래된 PC의 펌웨어가 2023년 키를 절대 받지 못하고, 세계가 그 키가 존재한다고 가정한다면 이상한 한계 상태에 빠질 수 있습니다. 기존 Linux 설치는 여전히 부팅되겠지만, 새 또는 업데이트된 배포판은 그렇지 않을 것입니다.
또한: 마이크로소프트가 처음 선보인 서버 리눅스 배포판: Azure Linux 4.0
행운을 빕니다, 귀하의 PC 벤더가 새로운 키를 포함하는 펌웨어를 배포하고, 리눅스 배포판이 새 키와 호환되도록 Shim을 업데이트하며, 모든 것이 원활히 작동하기를 바랍니다. 우리는 그렇게 운이 좋을 것입니다.
1. Update your firmware
각 주요 벤더는 Microsoft의 2023년 인증서와 다가오는 만료를 반영해 Secure Boot 키를 추가하거나 조정하는 업데이트를 꾸준히 출시하고 있습니다. 정확한 키 ID를 알 필요 없이 이 업데이트가 시스템에 전달되는 한 이득을 볼 수 있습니다.
일반적인 리눅스 머신에서는 벤더 지원 사이트에서 지난 1~2년 사이에 출시된 BIOS/UEFI 업데이트를 확인해야 합니다. 많은 시스템에서는 리눅스의 펌웨어 업데이트 스택을 사용할 수 있습니다,