Kahapon nai-publish namin dito sa blog ang tungkol sa balita Aya, isang silid-aklatan para sa paglikha ng mga driver ng eBPF sa kalawang at na ang layunin ng ito ay upang lumikha ng mas ligtas na mga driver o ang Proyekto ng Prossimo upang matiyak ang memorya ng kernel ng Linux na may Rust (dalawang magagaling na proyekto na magbibigay ng maraming mapag-uusapan sa mga susunod na buwan).
At sa isang bagay ng maikling panahon, naiulat ang iba't ibang mga kahinaan kung saan samantalahin ang mga bug sa eBPF at ito ay isang isyu kung saan ang mga developer ng kernel ay hindi tumigil sa pagtatrabaho at marahil ang Rust ang solusyon.
Ang dahilan para sa pagpindot sa paksang ito ay iyon kamakailan lamang ay inilabas ang balita na nakilala nila "Iba" na kahinaan sa kernel ng Linux (CVE-2021-33624) para sa proteksyon ng bypass laban sa mga kahinaan sa klase ng Spectre, dahil pinapayagan nitong gamitin ang subsystem ng eBPF upang matukoy ang nilalaman ng memorya bilang isang resulta ng paglikha ng mga kundisyon para sa mga haka-haka ng pagpapatupad ng ilang mga pagpapatakbo.
Nabanggit na ang kahinaan sanhi ito ng mga pagkabigo sa verifier, na ginagamit upang makita ang mga error at hindi wastong aktibidad sa mga programa ng BPF. Inililista ng verifier ang mga posibleng landas ng pagpapatupad ng code, ngunit hindi pinapansin ang anumang mga pagpipiliang sumasanga na hindi wasto mula sa pananaw ng itinakda ng mga semantiko ng arkitektura.
Kapag nagpapatakbo ng isang programa ng BPF, ang mga pagpipilian sa pagsasanga na hindi isinasaalang-alang ng verifier ay maaaring maling hulaan ng processor at isagawa sa isang speculative mode.
Sa mga apektadong system, maaaring magamit ng isang hindi kilalang programa ng BPF ang kahinaan na ito upang salain ang mga nilalaman ng di-makatwirang memorya ng kernel (at samakatuwid lahat ng pisikal na memorya) sa pamamagitan ng isang channel sa gilid.
Hal kapag pinag-aaralan ang operasyon na "load", ipinapalagay ng verifier na ang tagubilin ay gumagamit ng isang rehistro na may isang address na ang halaga ay palaging nasa loob ng tinukoy na mga limitasyon, ngunit ang isang umaatake ay maaaring lumikha ng mga kundisyon sa ilalim nito ang processor ay spekulatibong tatangkaing magsagawa ng isang kalakal na may isang address na hindi nakakatugon sa mga kundisyon ng pag-verify.
Ang pag-atake ng multo nangangailangan ng pagkakaroon ng isang tukoy na script sa may pribilehiyong code, na humahantong sa haka-haka na pagpapatupad ng mga tagubilin. Sa pamamagitan ng pagmamanipula ng mga programang BPF na ipinapasa para sa pagpapatupad, posible na makabuo ng mga naturang tagubilin sa eBPF at salain ang mga nilalaman ng memorya ng kernel at di-makatwirang mga lugar ng pisikal na memorya sa pamamagitan ng mga channel sa gilid.
Bukod dito, maaari mong markahan ang isang tala tungkol sa epekto sa pagganap ng mga assets upang maprotektahan laban sa klase ng Spectre ng mga kahinaan.
Ang tala na ito ay nagbubuod ng mga resulta pag-optimize sa pag-optimize ng debugger (Record at Replay), isang beses nilikha ng Mozilla upang i-debug ang mga hard-to-ulit na error sa Firefox. Ang pag-cache sa mga tawag sa system na ginamit upang mapatunayan ang pagkakaroon ng mga direktoryo ay binawasan ang operasyon ng "mga mapagkukunan ng" para sa proyekto ng pagsubok mula 3 minuto 19 segundo hanggang 36 segundo.
Nagpasya ang may-akda ng pag-optimize na suriin magkano ang magbabago pagganap pagkatapos hindi paganahin ang proteksyon ng Spectre. Matapos i-boot ang system na may parameter na "mitigations = off", ang oras ng pagpapatupad ng "mga mapagkukunan ng rr" nang walang pag-optimize ay 2 minuto 5 segundo (1.6 beses na mas mabilis) at may pag-optimize ng 33 segundo (9% mas mabilis).
Nagtataka, hindi pagpapagana ng Proteksyon ng multo hindi lamang binawasan ang runtime ng antas ng antas ng kernel sa 1.4 beses (mula 2 min 9s hanggang 1 min 32s), hatiin din nito ang oras ng pagpapatupad sa puwang ng gumagamit (mula 1 min 9s hanggang 33s), maaaring dahil sa pagbawas sa kahusayan ng cache ng CPU at TLB ay na-reset kapag pinagana ang proteksyon ng Spectre.
Ang problema ay lumitaw mula noong 4.15 paglabas ng kernel at ay naayos na sa anyo ng mga patch, na sa kasalukuyan ay hindi pa rin nakakaabot sa lahat ng mga pamamahagi, kaya inirerekumenda sa mga gumagamit na sa mga araw na ito ginagawa nila ang mga nauugnay na update sa lalong madaling matanggap nila ang mga notification.
Si nais mong malaman ang tungkol dito, maaari mong suriin ang mga detalye Sa sumusunod na link.