James Bottomley가 블로그에 올린 두 게시물의 번역입니다. 첫 번째 게시물은 1 월 2013 일에 작성되었으며 "LCAXNUMX 및 보안 부팅 재구성"이라고합니다.
한동안 소식이 뜸했죠. 그래서 리눅스 재단의 보안 부트 로더(Secure Boot Loader) 개발 현황을 알려드리려고 합니다(특히 LCA2013에서 발표된 내용입니다). ( 슬라이드 링크 )
문제의 핵심은 커널 개발자인 GregKH(Greg Kroah-Hartman)가 12월 초에 제안된 Pre-BootLoader가 현재 형태로 Gummiboot에서 작동하지 않는다는 사실을 발견했다는 것입니다. 이는 모든 부트로더를 지원한다는 Linux Foundation의 목표를 달성하지 못한다는 것을 의미했기 때문에 실망스러운 일이었습니다. 조사 결과 이유는 간단했습니다. Gummiboot는 GRUB처럼 거대한 링크 로더가 아닌, UEFI 플랫폼에서 사용 가능한 모든 서비스를 활용하는 작고 간단한 부트로더를 만들 수 있음을 보여주기 위해 개발되었습니다. 하지만 이 때문에 Gummiboot는 BootServices->LoadImage() 함수를 사용하여 커널을 부팅하는데, 이는 부팅될 커널이 UEFI 플랫폼의 보안 부팅 검사를 거쳐야 한다는 것을 의미합니다. 원래 Pre-BootLoader는 shim (Mathew Garrett의 부트로더)처럼 PE/Coff 링크 로딩을 사용하여 보안 부팅 검사를 우회하도록 설계되었습니다. 불행히도 이는 Pre-BootLoader에서 실행되는 모든 프로그램이 로드하려는 모든 항목에 대한 보안 부팅 검사를 통과하기 위해 링크 로딩을 사용해야 한다는 것을 의미하며, 따라서 의도적으로 링크 로더가 아닌 Gummiboot는 이 방식에서 작동하지 않습니다.
그래서 저는 재구성하고 다시 작성해야했습니다. 이제 문제는 "정책을 준수하는 Microsoft에서 서명 한 링크 로더를 만드는 방법"에서 "부트 로더의 모든 자식이 BootServices-> LoadImage () 기능을 사용할 수있게하는 방법"으로 바뀌 었습니다. 그들의 정책을 준수하는 방법. 다행히 자체 아키텍처 보안 프로토콜을 설치하여 UEFI 플랫폼 서명 인프라를 가로 챌 수있는 방법이 있습니다. 불행히도 플랫폼 초기화 사양은 실제로 UEFI 사양의 일부가 아니지만 고맙게도 찾을 수있는 모든 Windows 8 시스템에서 구현됩니다. 새로운 아키텍처는 해당 프로토콜을 가로 채고 자체 보안 검사를 추가합니다. 그러나 두 번째 문제가 있습니다. 아키텍처 보안 프로토콜 콜백에있는 동안 반드시 UEFI 시스템 화면을 소유하고있는 것은 아니므로 바이너리 실행을 인증하기 위해 사용자 테스트를 수행하는 것이 완전히 불가능합니다. 다행히도이를 수행하는 비대화 형 방법이 있으며 이것이 바로 SUSE MOK (Machine Owner Key) 메커니즘입니다. 따라서 Linux Foundation Pre-BootLoader는 이제 표준 MOK 변수를 사용하여 인증 된 이진 해시를 저장하도록 발전했습니다.
이 모든 것의 결론은 이제 Gummiboot와 함께 Pre-BootLoader를 사용할 수 있다는 것입니다 (LCA2013의 데모에서 수행 된 것처럼). 부팅하려면 2 개의 해시를 추가해야합니다. 하나는 Gummiboot 자체 용이고 다른 하나는 부팅하려는 커널 용이지만 실제로는 전체 부팅 시퀀스를 제어하는 단일 보안 정책이 있기 때문에 실제로 좋습니다. Gummiboot 자체도 보안 부팅으로 인한 충돌을 인식하고 등록 할 해시를 알려주는 메시지를 표시하도록 패치되었습니다.
나는 새로운 아키텍처가 어떻게 작동하는지 설명하는 별도의 게시물을 할 것이지만 지난달에 일어난 일을 설명하는 것이 더 나을 것이라고 생각했습니다.
그리고이 두 번째 포스트는 그가 어제 "Launched the Linux Foundation Secure Boot System"이라고합니다.
약속대로 여기에 Linux Foundation Secure Boot System이 있습니다. 실제로 Microsoft에서 6 월 XNUMX 일에 공개했지만 여행, 회의 및 회의를 통해 오늘까지 모든 것을 확인할 시간이 없었습니다. 파일은 다음과 같습니다.
프리로더.efi (md5sum 4f7a4f566781869d252a09dc84923a82)
HashTool.efi (md5sum 45639d23aa5f2a394b03a65fc732acf2)
또한 부팅 가능한 미니 USB 이미지를 만듭니다. (dd를 사용하여 USB에 설치해야합니다. 이미지에는 GPT 파티션이 있으므로 전체 디스크를 사용합니다.) 커널이 있어야하는 EFI 셸이 있으며 gummiboot를 사용하여로드합니다. 여기에서 찾을 수 있습니다. (md5sum 7971231d133e41dd667a184c255b599f).미니 USB 이미지를 사용하려면 loader.efi (\ EFI \ BOOT 폴더에 있음) 및 shell.efi (루트 폴더에 있음)에 대한 해시를 입력해야합니다. KeyTool.efi의 사본도 포함되어 있으며 실행하려면 해시를 입력해야합니다.
KeyTool.efi는 어떻게 되었습니까? 원래 서명 된 키트의 일부가 될 예정이었습니다. 그러나 테스트 중에 Microsoft는 UEFI 플랫폼 중 하나의 버그로 인해 프로그래밍 방식으로 플랫폼 키를 제거하는 데 사용될 수 있으며, 이는 UEFI 보안 시스템을 망칠 수 있음을 발견했습니다. 이 문제를 해결할 수있을 때까지 (루프에 개인 공급 업체가 있음), 실행하려는 경우 MOK 변수를 추가하여 권한을 부여 할 수 있지만 KeyTool.efi에 서명하는 것을 거부했습니다.
작동하는 것과 그렇지 않은 것에 대한 피드백을 수집하는 데 관심이 있으므로 이것이 어떻게 진행되는지 알려주십시오. 특히 보안 프로토콜 재정의가 일부 플랫폼에서 작동하지 않을 수 있다는 점이 우려되므로 특히 작동하지 않는지 알고 싶습니다.
푸엔테스 :
http://blog.hansenpartnership.com/lca2013-and-rearchitecting-secure-boot/
http://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/
좋은 소식인지 나쁜 소식인지 결정하십시오.