Dy lajme në lidhje me ngarkuesin para-nisës

Ato janë përkthimet e dy postimeve që James Bottomley ka marrë në blogun e tij. Postimi i parë u bë më 1 shkurt dhe quhet "LCA2013 dhe Ristrukturimi i Çizmes së Sigurt"

Isha i qetë për pak, kështu që është koha të jap një azhurnim mbi atë që po ndodh me Loader Secure Boot të Fondacionit Linux (veçanërisht që ishte paraqitur në LCA2013). (Lidhje me diapozitivët)

Thelbi i problemit është që GregKH (zhvilluesi i kernelit Greg Kroah-Hartman) zbuloi në fillim të dhjetorit që Pre-BootLoader i propozuar nuk do të funksiononte në formën e tij aktuale me Gummiboot. Kjo ishte disi tronditëse sepse do të thoshte se nuk po përmbushte misionin e Fondacionit Linux për aktivizimin e të gjithë bootloaders. Në hulumtim, arsyeja ishte e thjeshtë: Gummiboot u krijua për të demonstruar se mund të krijonit një bootloader të vogël dhe të thjeshtë që do të përfitonte nga të gjitha shërbimet e disponueshme në platformën UEFI në vend që të ishte një ngarkues masiv i lidhjeve si GRUB. Fatkeqësisht do të thotë që ju të bërtisni kernel duke përdorur funksionin BootServices-> LoadImage (), që do të thotë që kerneli që do të niset duhet të kalojë nëpër kontrollet e sigurta të nisjes në platformën UEFI. Fillimisht Pre-BootLoader, si spesor (Bootloader i Mathew Garrett), u shkrua për të përdorur ngarkimin e lidhjes PE / Coff për të mposhtur kontrollet e sigurta të nisjes. Për fat të keq, kjo do të thotë që diçka e drejtuar nga Pre-BootLoader duhet të përdorë gjithashtu ngarkimin e lidhjeve për të mposhtur kontrollet e sigurta të nisjes për gjithçka që dëshiron të ngarkojë dhe për këtë arsye Gummiboot, e cila qëllimisht nuk është një ngarkues lidhjesh, nuk do të funksionojë sipas kësaj skeme.

Kështu që unë u detyrova të ristrukturoj dhe rishkruaj: Problemi tani shkoi nga "si të krijojmë një lidhës ngarkues të nënshkruar nga Microsoft që i bindet politikave të tyre" deri te "si për të mundësuar që të gjithë fëmijët e ngarkuesit të boot të përdorin funksionin BootServices-> LoadImage () të mënyrë për t'iu bindur politikave të tyre. Për fat të mirë, ekziston një mënyrë për të kapur infrastrukturën e nënshkrimit të platformës UEFI duke instaluar protokollin tuaj të sigurisë së arkitekturës. Për fat të keq, specifikimi i inicimit të platformës nuk është në të vërtetë pjesë e specifikimit të UEFI, por fatmirësisht zbatohet nga çdo sistem Windows 8 që mund të gjeni. Arkitektura e re kap atë protokoll dhe shton kontrollin e saj të sigurisë. Sidoqoftë, ekziston një problem i dytë: Ndërsa jemi në thirrjen e protokollit të sigurisë së arkitekturës, ne nuk kemi domosdoshmërisht ekranin e sistemit UEFI, duke e bërë plotësisht të pamundur të bësh një test përdoruesi për të autorizuar ekzekutimin e binarit. Për fat të mirë, ekziston një mënyrë jo-ndërvepruese për ta bërë këtë dhe kjo është mekanizmi SUSE Machine Owner Key (MOK). Prandaj, Linux Foundation Pre-BootLoader tani ka evoluar për të përdorur variablat standardë të MOK për të ruajtur skedarët binarë të autorizuar.

Rezultati i gjithë kësaj është që tani mund të përdorni Pre-BootLoader me Gummiboot (ashtu si u bë në demonstrim në LCA2013). Për të nisur, duhet të shtoni 2 hashe: një për vetë Gummiboot dhe tjetrin për kernelin që dëshironi të boot, por në fakt është një gjë e mirë sepse tani keni një politikë të vetme sigurie që kontrollon të gjithë sekuencën e nisjes. Vetë Gummiboot gjithashtu u rregullua për të njohur një përplasje për shkak të nisjes së sigurt dhe shfaq një mesazh që ju tregon se cilin hash duhet të regjistroheni.

Unë do të bëj një post të veçantë duke shpjeguar se si funksionon arkitektura e re, por mendova se do të ishte më mirë të shpjegoja se çfarë ndodhi muajin e kaluar.

Dhe këtë postim të dytë që ai bëri dje dhe quhet "Launch the Linux Foundation Secure Boot System"

Siç është premtuar, këtu është Sistemi i Sigurisë Boot i Fondacionit Linux. Në të vërtetë na u lëshua nga Microsoft në 6 Shkurt, por me udhëtimet, konferencat dhe takimet nuk kisha kohë të vërtetoja gjithçka deri më sot. Dosjet janë:

PreLoader.efi (md5sum 4f7a4f566781869d252a09dc84923a82)
HashTool.efi (md5sum 45639d23aa5f2a394b03a65fc732acf2)
Krijo gjithashtu një imazh të bootable mini-USB; (Duhet ta instaloni në USB duke përdorur dd; imazhi ka ndarje GPT, kështu që përdor të gjithë diskun). Ka një guaskë EFI ku duhet të jetë bërthama dhe përdor gummiboot për ta ngarkuar atë. Mund ta gjeni këtu (md5sum 7971231d133e41dd667a184c255b599f).

Për të përdorur imazhin mini-USB, duhet të futni hashat për loader.efi (në dosjen \ EFI \ BOOT) dhe shell.efi (në dosjen rrënjë). Ai gjithashtu përfshin një kopje të KeyTool.efi, duhet të futni hashin për të ekzekutuar.

Çfarë ndodhi me KeyTool.efi? Fillimisht do të ishte pjesë e kompletit tonë të nënshkruar. Sidoqoftë, gjatë testimit Microsoft zbuloi se për shkak të një defekti në një nga platformat UEFI, ai mund të përdorej për të hequr çelësin e platformës në mënyrë programatike, gjë që do të prishte sistemin e sigurisë UEFI. Derisa të mund ta zgjidhim këtë (kemi në treg shitësin privat), ata nuk pranuan të nënshkruanin KeyTool.efi edhe pse mund ta autorizoni duke shtuar variabla MOK nëse doni ta ekzekutoni.

Më tregoni se si shkon kjo, sepse unë jam i interesuar të mbledh reagime për atë që funksionon dhe çfarë jo. Në veçanti, unë jam i shqetësuar se mbikëqyrja e protokollit të sigurisë mund të mos funksionojë në disa platforma, kështu që unë veçanërisht dua të di nëse nuk funksionon për to.

Fuentes:

http://blog.hansenpartnership.com/lca2013-and-rearchitecting-secure-boot/

http://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/

Vendosni nëse është një lajm i mirë apo i keq.