Fórumok
Egy frissen nyitott bug szerint az RHSA-2020:3216 biztonsági frissítés a Grub2-höz bootolhatatlanná teszi a RHEL rendszereket.
Egy frissen nyitott bug szerint az RHSA-2020:3216 biztonsági frissítés a Grub2-höz bootolhatatlanná teszi a RHEL rendszereket.
Hozzászólások
az de szép, gratulálunk hozzá
Ó, a picsába, ezek a majmok teljesen elrontják a játékomat, mert ezután majd minden Windows 10 gyalázó hozzászólásomnál tutira ezzel fognak visszavágni a hobbitkák, hogy dehát a linux is szar.
És a legrosszabb, hogy igazuk van, márpedig azt utálom. :-(
Mé', hát nem az? :)
Mindegyik OS másképp rossz. Ezen nincs mit szépíteni.
+1, és hogy mennyi minden mással van ez még így! :D
De legalabb nem orc-ok vagyunk :D
Mondd nekik, hogy a másikra mutogatás sosem érv, még akkor sem, ha igaz. :)
Oldschool Computer - http://oscomp.hu
Nem fognak visszavágni. Álhír. Mindenki hazudik, monnnyonle, whatever. Volt nem is rég egy másik fórumon egy szagértő gyerek, jött nekem hőbörögni, hogy az Arch, amit használok, az nem jó szerverre, meg ilyen hobbista instabil rolling, bezzeg az RHEL, az micsoda vállalati, meg hosszútávú support meg kutyapöcse, böff. Közben meg Archon nem volt semmi gondom, bár az igazsághoz hozzátartozik, hogy GRUB-ot sem használok, systemd boot megy helyette, illetve nem systemd-s disztrón EFI stub boot, amikor mindjárt a kernel bootol. Tehát nem, nem ×4r a Linux, csak nem ilyen enterspájz bullshitet kell használni belőle. Hiszen az egész linuxozásnak az a lényege, hogy az ember dönti el, hogy mit akar, milyen bootolás/bootmanager, milyen initrendszer, milyen grafikus felület/protokoll, stb.. Nem muszáj használni sem ilyen vöröskalapot, se GRUB-ot, senki nem kényszerít rá, ezek nem egyenlőek a GNU+-/Linuxszal. Ez nem Windows, hogy egyféle megoldást kell használni mindenkinek, amit elé raknak, meg amit egy multi előírt nekik.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Debian-t is. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966575
"...On a Acer TravelMate 5735Z with Debian Sid/unstable..." -nem is olvastam tovább... :)
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Pedig lett volna értelme, mert a Mint mellett pl. az AWS Ubuntu instance-ok is érintettek:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889509
Azok nem érdekelnek. :)
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Debian alapú distrókat is?
Nem Ubuntu, upgrade ma frissíteni akarta a grubot is, de emiatt kihagytam. Azóta javították már? Csak EFI Bios-os gépeken jön elő a hiba,
kösz
Ez is csak arra bizonyíték, hogy a Secure Boot jó nekünk.
Nyilván. Ha nem volna jó, akkor nem volna a linuxban ugye.
Ez a biztonság irányába tett nagy lépés. Ha nem bootol a gép, feltörni sem nagyon tudják. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Öntsd ki betonnal, az jobb... Bár akkor tényleg csak feltörni lehet...
:)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Aszittem, te vagy a B Panther Linux fejlesztője.
Az oldalad, http://panther.inf.elte.hu hiányzik
Ja, '13ban elmúlta magát. Ami hasznos, a githubon kint van, a vas meg eladó /elvihető. Egy HP ProLiant D380 g3 vagy micsoda, rég volt... Nem volt hely a gépnek, de elvileg működik.
Azon a gépen volt a gentoo.inf.elte.hu is, a géppel ment...
Nem, a black pantherhez semmi közöm.
Csak már jó lenne, ha lenne megoldás is a hibára.
A laptopomon lévő CentOS 8-nál nyomtam egy dnf upgrade-et 3 napja, majd az első reboot-nál nem indult el a masina. Eleinte gyanútlanul csak néztem, aztán csak mentem befelé az erdőbe. Kellett egy idő, mire világossá vált, hogy az EFI körül kell keresgélni. Aztán izzadtam vagy 3 órát, mire visszahoztam a halálból. Többrétű feladat volt, USB CentOS8 telepítő -> rescue mód -> a merevlemezen lévő grub helyrekalapálása -> utána a gépről csak valami rescue módban indult és a telepített kerneleket is helyre kellett lökni.
Hatalmas szívás, nagyon kellett a 20 éves rutin, hogy ne legyen újratelepítés belőle. Utólag is gratulálok a RedHat-es srácoknak. :-((
Régen minden jobb volt.
Bezzeg a lilo!
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Ugye, mint a kőkorszak: egy kernel-loader, ami nem csinál mást, mint adott helyről betölti a kernelt... Nem tud N+1 fájlrendszert olvasni, nincs benne se mesterséges intelligencia, se Microsoft által kiállított certiaficate... Naná, hogy nem trendi.
Ha nem ismer filerendszert, hogyan tölti be a kernelt, ha az fragmentált, nem címfolytonos a háttértáron?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Gondolom, még ha a kernel(image) lehet is fragmentált, a /boot/map nem. A bootszektor tartalmazza ennek a 'map'-nak címét és hosszát, a 'map' pedig a kernel(ek) (fragmentjeinek) helyét.
Akkor ezek szerint a map file egy kezdetleges filerendszer leíró lényegében? Bevallom, nem ismerem közelebbről a lilo-t.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
kb.
ha lecserelted a kernelt, le kellett futtatni a lilo parancsot, ami vegignezte a kernel blokkjai fizikailag hol vannak a disken, es letarolta az lba vagy chs cimeket a map fileba. amilyen egyszeru olyan nagyszeru, evtizedekig jol mukodott.
es igazabol az uefi miatt nem is kene az elilo/grub mar, meg lehetne ugy csinalni a kernel imaget hogy kozvetlen induljon efi-bol.
Ezzel az UEFI-vel ne is bosszants! Valamikor fordítottam kernelt forrásból, és azért nem tudtam beboot-olni, mert nem volt aláírva. Gyanítom, nem is írhattam volna alá, mert akkor bárki aláírhatná a rosszindulatú kódját. Egyáltalán kiknek van ehhez aláíró kulcsa, s ők hogyan szerezték?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
UEFI Signing Requirements
Ezt most biztosan nem fogom elolvasni, de nyugtass meg, hogy nem csak a Microsoft írhat alá!
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
olyan írhat alá, akinek a certje bent van a ms által aláírt shim binaryben
https://wiki.freebsd.org/SecureBoot
Oldschool Computer - http://oscomp.hu
Ez azt jelenti, hogy most már gyakorlatilag az összes hardware-t a Microsoft uralja? Ebbe miért mennek bele a hardware gyártók?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Hogy kapjanak Windows 8 certet és árulhassák Windows-zal a gépeiket... (egyébként én még olyan géppel nem találkoztam, aminél ne lehetett volna letiltani az SB-t)
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
Amikor a Secure Boot megjelent, sok olyan gép jött ki, amin nem lehetett tiltani. "Szerencsére" később ez változott, már régóta nincs ilyen probléma.
Úgy emlékszem, hogy az Acer ES1-132 notebook-on nem lehet.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Youtube-videó szerint a szokásos "jajúristenkellasupervisorpassword" megoldás van (miután beállítottál egy jelszót, már engedi változtatni; az ölemben levő Acer TravelMate-n ugyanígy működik [és szokásos HP bashing: náluk láttam már olyat, hogy beállítod a jelszót, utána újraindítod a gépet (!), és akkor engedi csak letiltani... no komment]).
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
Ja, tehát ha csinálok erre az EFI felületre jelszót, akkor kikapcsolhatom. Eszembe nem jutott volna. Köszönöm.
Amúgy nem konkrétan okoz egyelőre problémát, mert a Fedora team aláírja valahogyan a kernelt - gondolom, az MS szolgáltatásával -, sokkal inkább az töltött el rémülettel, hogy az MS-nek piaci zsarolással sikerült a desktop hardware-eket magához láncolnia, ami így a desktop Linux és BSD végét jelenthette volna.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Nem a kernelt iratták alá az ms-sel, hanem a shimjüket, a SecureBoot ugyanis a bootloadereket tölti be (ha alá vannak írva). Az ms ugyanis közölte, hogy GPLv3-as license-ű bootloader nem kaphat ms certification-t, így a GRUB-ot is kizárták. (Ha valaki, hát én nem vagyok GPL faggot, de ez nettó pofátlanság volt.) Ezért a különféle projektek ezt úgy oldották meg, hogy van egy first stage loaderjük, ami nem GPLv3-as, így van aláírása és ez tölti be a GRUB-ot. Hogy a microsoft indoklása és ez az egész balfaszkodás a certification-ökkel mekkora bullcrap, azt tessék elolvasni a Pene által adott linken; a Rufus loader írója tökéletesen összefoglalta a dolgot. Az meg, hogy maga a SecureBoot mennyire nem jó semmire, az most pláne kiderült a BootHole kapcsán.
Oldschool Computer - http://oscomp.hu
>de ez nettó pofátlanság volt
a gplv3 anti-tivoization clause miatt lehetetlen lenne megoldani
A jogi részhez én nem értek, azt meg nem vitatom, hogy a GPL egy rettenet, ami egy csomó kötelezettséget pakol arra, aki egy GPL-es cucchoz hozzányúl. Ugyanakkor, a Rufus fejlesztője leírta, hogy miért volt bullshit az ms indoklása:
A koncepció hatékonysága már a Golden Key pániknál látszott, de most pláne látszik, hogy az egész nem ér egy vödör vizet, hiszen a GRUB ugye nincs a GPL miatt aláírva és mégis sikerült rajta keresztül a bekapcsolt SecureBoot ellenére is a kódfuttatás.
Ami miatt nettó pofátlanság volt a GPLv3-as cuccok kizárása, az pont az, amit te leírtál, hogy az ms mindenképpen megkerülhetetlen szereplő, ha SecureBoot aláírást akarsz, egyszóval itt leginkább arról volt szó, hogy az ms bepróbálkozott azzal, hogy ők döntik el, hogy mi futhat egy PC-n. Na, ez a nettó pofátlanság. Mégis milyen alapon dönti el pár koszos jenki, hogy egy random user mit tölthet be bootloader gyanánt a saját gépén? Persze kikapcsolható...még. Anno a windows 8 idején a kritikák miatt az ms kötelezővé tette a kikapcsolhatóságot, de a windows 10 pl. már egyáltalán nem követeli meg, csak az OEM-eken múlik.
Oldschool Computer - http://oscomp.hu
a secureboot egy elhibázott elképzelés, szerintem üzemeltetőmacik találták ki
igen, finoman szólva szerencsétlen az ms szál
igen, az egészben az a legjobb, hogy kikapcsolható
a gplv3 nem pofátlanság miatt van kizárva, hanem amiatt, hogy az egyik kitétele ellentétes az egész folyamat lényegével
> a secureboot egy elhibázott elképzelés, szerintem üzemeltetőmacik találták ki
ROFL. :D
> a gplv3 nem pofátlanság miatt van kizárva, hanem amiatt, hogy az egyik kitétele ellentétes az egész folyamat lényegével
Nem úgy értettem, hogy a GPLv3-at pofátlanság miatt zárták ki, hanem, hogy az egész, úgy ahogy van pofátlanság. A jogi részhez meg mondom nem értek...csak az nem tiszta, hogy a shimeket hogy tudják aláírni, ha azok GPLv3-as cuccokat is be tudnak tölteni? Vagy valahol baki van a Rufus fejlesztőjének levezetésében?
Oldschool Computer - http://oscomp.hu
"igen, az egészben az a legjobb, hogy kikapcsolható"
Ha jol emlekszem, az MS ugy definialta a szabvanyt annak idejen, hogy x86-on kikapcsolhatova kell tenni, es ARM-on kotelezove kell tenni. A kellemetlen resze most kezdodik.
Fene tudja. Ha igény mutatkozik rá, talán lesz nyílt forrású hardware kapcsolási rajzzal, a bootloader forráskódjával, mindennel, ami nem EFI.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
"Az úgy kezdődött, hogy visszaütött..."
Hány szabadalomsértés volt valódi és hány csak az ms patent-trollkodása? Az ms a számítógépek leállítását is levédte; hát így nem nehéz megsérteni valamelyik szabadalmát.
Oldschool Computer - http://oscomp.hu
Hát ugye az is "úgy kezdődött, hogy visszaütött..." :)
pont ma dobta elém a Rufus ezt a figyelmeztetést USB-s win telepítő készítése után, elég jó összefoglalója a secure boot hoaxnak: https://github.com/pbatard/rufus/wiki/FAQ#Why_do_I_need_to_disable_Secure_Boot_to_use_UEFINTFS
Szerintem az nem az UEFI, hanem a Secure Boot nevű része / kiegészítése, ami aláírósdit játszik.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Igen, de az ezzel jött. Hagyományos MBR alapú boot esetén nincs secure boot.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Bocs, tudom hogy te csináltad az Mplayer.
De most is le kell futatni az update-grub parancsot fordítás után, valszeg a System.map felelhet meg a lilo map-jának.
távolról sincs semmi közük egymáshoz
az update-grub csak a grub.cfg-be irja bele hogy melyik fajl a kernel fajl, es azt merre talalja meg. utana a grubnak kell osszekaparnia a raid tombot, lvm-et, fs-t, aztan toltheti a megadott kernel fajlt.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
> grubnak kell osszekaparnia a raid tombot, lvm-et, fs-t, aztan toltheti a megadott kernel fajlt.
Ezt a sokmindent akár egy külön komponensbe is lehetne tenni (elválasztva az üzleti logikától), aminek a neve lehetne mondjuk 'nukleosz'. Vagy esetleg 'kernel'. Persze ilyenek vannak készen is, például a Minix vagy a Linux.
Szerk: Természetesen van olyan, hogy egy számítógép indítását egy másik (kisebb) számítógép végzi (pl. 'szervíz processzor' néven).