사전 부트 로더에 관한 두 가지 뉴스

James Bottomley가 블로그에 올린 두 게시물의 번역입니다. 첫 번째 게시물은 1 월 2013 일에 작성되었으며 "LCAXNUMX 및 보안 부팅 재구성"이라고합니다.

저는 잠시 조용했습니다. 이제 Linux Foundation의 Secure Boot Loader (특히 LCA2013에 등장)에서 무슨 일이 일어나고 있는지에 대한 업데이트를 제공 할 때입니다. (슬라이드에 연결)

문제의 핵심은 GregKH (커널 개발자 Greg Kroah-Hartman)가 XNUMX 월 초 제안 된 Pre-BootLoader가 Gummiboot에서 현재 형태로 작동하지 않는다는 것을 발견 한 것입니다. 이는 모든 부트 로더를 활성화하는 Linux Foundation의 임무를 수행하지 않는다는 것을 의미했기 때문에 다소 어렵습니다. 연구에서 이유는 간단했습니다. Gummiboot는 GRUB와 같은 대규모 링크 로더가 아닌 UEFI 플랫폼에서 사용 가능한 모든 서비스를 활용할 수있는 작고 간단한 부트 로더를 만들 수 있음을 보여주기 위해 만들어졌습니다. 불행히도 BootServices-> LoadImage () 함수를 사용하여 커널을 부팅한다는 의미입니다. 즉, 부팅 할 커널이 UEFI 플랫폼에서 보안 부팅 검사를 거쳐야합니다. 원래 Pre-BootLoader는 틈 메우는 나무 (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/

좋은 소식인지 나쁜 소식인지 결정하십시오.