Elérhető a Chaoskey hardveres RNG 1.0-s verziója

 ( trey | 2016. szeptember 8., csütörtök - 15:44 )

chaoskey #1 chaoskey #2

Nemrég volt szó arról, hogy a nyílt forrás veterán Keith Packard egy mindenki számára elérhető, USB-re csatlakoztatható, hardveres random number generator eszközön dolgozik Chaoskey néven. Most Keith bejelentette, hogy elérhető Chaoskey 1.0-s verziója. Megvásárolható 40 dollárért (10 darabtól 35 dollárért, 25 darabtól 30 dollárért) az Altus Metrum store-ból.

A Chaoskey-t a Linux kernel a 4.1-es verzióról fogja támogatni. Használatához csak USB-re kell csatlakoztatni a Chaoskey-t és a driver automatikusan hozzáadja a hardver által biztosított entrópiát a kernel pool-hoz.

Részletek itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Ennyit bőven megér ha valóban megbízható.

remélem későbbi generációi összemennek olyan méretbe, mint a memóriakártya-olvasók, vagy pl. a yumikey, és nem fog kilógni egyáltalán a gépből, akkor szerintem elég könnyű lesz találni neki helyet egy laptopban is

Vagy modjuk beepithetnek a CPU -ba, es akkor nem kene kulon chip sem ;-)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

amennyire én tudom, ennek pont az az értelme, hogy ha már nem bízol a hardware gyártódban, akkor itt egy nyílt (?) eszköz, amivel egy nagy sebezhetőséget betömhetsz

(ha rosszul értelmezem javítsatok ki)

Miert lenne megbizhatob az a chip ami ebben az usbs micsodaban van ?


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem a chip csinálja az rng-t, hanem fizikai tüneményen alapul. Ugyanúgy, mint a bármelyik más gyártóé.

Ugyan ugy be van tokozva egy fekete dobozba, tok mindegy hogy min alapul.

Electron micrsocope meg lat dologokat mindket esetben,
de hat kinek van olyan, es kinek van turelme ertelmezni a lattotakat.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Azt akarod mondani, hogy mást valósítanak meg, mint amit dokumentálnak? Jó, de semmi akadálya, hogy megépítsd jól. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem csak. Valahol írták, hogy régi, gyenge, hw rng-t nem tartalmazó processzorok mellé való.
Nyílt == előnyös. Egymillió emberből valószínűleg egy se tud vele mit csinálni. :)

https://en.wikipedia.org/wiki/RdRand ezzel mi a (bizonyitott) baj, mar akinek van.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"Reception" szekció

Van -e _bizonyitott_ gyengesege az utasitasitasnak az Intel(/AMD) cpu-k ban ?

Azt latom hogy mindenki mondogatja, hogy biztos a gonosz gyartok meg `a kormany` tettek / tesznek bele valmit, de nem latok semmi bizonyitekot erre.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

http://www.rambus.com/wp-content/uploads/2015/08/Intel_TRNG_Report_20120312.pdf

Most nem olvastam el megint, de úgy rémlik, az van benne, hogy a HW entrópia forrásból (ES) származó számot időnként benyomja egy álvéletlen sorozatot generáló algoritmusba, és ez az algoritmus szerintük nem elég jó, azaz néhány minta után megjósolható a következő érték.

A vegen nem panaszokodtak.
Valamenyi minta utan a minden pseudo random generator megjosolhato, pont ezert adnak hozza kis `igazi veletlent`.

Ha nagy mennyisegu es `jo` veletlen szamra van szukseged gyorsan akkor a pseudo random generatorodat, kiegszeted valamival
ami entropiat visz bele.

/dev/urandom is teljesen jo crypto-ra, hasonlon kevert. (Mar legtobb paranoid is leszokott /dev/random -rol)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ilyenek ezek a fedett titkosszolgálati NOBUS műveletek, nehéz őket egyértelműen bizonyítani, ezért csak korábbi történelmi tényekre tudunk alapozni, amelyek ehhez hasonló eseteket bizonyítanak és olyan szivárogtatásokat tudunk figyelembe venni, amelyek valószínűsítik azt a régóta létező logikus sejtést, hogy jelenleg is nagy erővel próbálják a biztonsági és kriptográfiai védelmeket gyengíteni az ipar teljes spektrumán, így a hardvergyártóktól a szoftvereken át a szabványügyi hivatalokig, ahol ezeket véglegesítik. Lásd. IBM Lucifer 128bit key vs. DES 56bit, Clipper chip NSA backdoor, Dual_EC_DRBG backdoor, WeakDH, stb.

De fordítsuk meg a kérdést, elvégre az lenne a normális hozzáállás: van-e bizonyíték arra, hogy ezek a processzorban lévő megoldások biztonságosak?

Az eloszlast meg lehet merni, abbol lehet valamit modani a josagarol, mint barmelyik rnd gen esetben.
A fent likelt pdf szerint nem rosz az eredmeny.

De a paranoidok majd jonek azzal, es ha meg tippeli, hogy foobar kulcsot generalsz akkor atvalt a gonosz modba ;-)
Ezt a chip tenyleges `szetszedese` es tanulmanyozasa nelukl nehez lenne megmondani,
de eleg nehez megtippelni mikor legyen gonosz, ugyhogy feltetezem nincs benne ilyen.

Fent linkelt pdf szerint soha ne bizz egyetlen rnd forassba,
nem mondja, hogy ez a forras rosz lenne.

BTW; a chip hasznalhatna tobb forrast onmagaban is,
de gondolom a paranoidoknak ez sem lenne eleg.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Szia Kurt!

Az eloszlast meg lehet merni, abbol lehet valamit modani a josagarol, mint barmelyik rnd gen esetben.

Aha persze, ahogy azt Móricka elképzeli. Ha az RNG felváltva generálja, hogy 0 aztán 1 aztán 0 aztán 1, akkor az eloszlás tökéletes lesz, csak épp marhára nem véletlen.

Miből gondolod, hogy az a szervezet, amelyik 100 éve folyamatosan minden évben dollár 10 és 100 milliókat költ ilyen jellegű kutatásokra és fejlesztésekre, ugyanannyira primitíven gondolkozik a véletlenszám generátorokról, mint te?

A szukseges definicio valami ilyesmi, hogy az osszes elozo bit ismereteben, ne lehessen 50% tol jobb esélyél meg tippelni a koveztkezot.

A reszletekbe nincs ertelme bele meni.

"folyamatosan minden évben dollár 10 és 100 milliókat költ ilyen jellegű kutatásokra és fejlesztésekre, ugyanannyira primitíven gondolkozik a véletlenszám generátorokról, mint te?"

A szokasaso crypto FUD ? ;-)

Elszor is, csak a kesobbi designeoknal lenne valoszinu a ..

Lenyeg:
1. nem bizonyitottan rosz.
2. Erdemes mindig ovatosnak lenni.

Egyetertesz -e kettovel ?


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Kérem a dzsojsztikról is írjon néhány szavat!

Úgy hívják amiben szenvedsz, hogy Dunning–Kruger effektus.

Azt tudjuk hogy hulye vagyok, ezen nem fogunk ossze veszni.

Mivel nem ertesz egyett ?

1.rnd soha sem tudhatod hogy valoban rnd, (valamit modhatsz rola, egy veges szamu minta alapjan..)
2.intel megolasarol nincs bizonyitekunk, hogy rosz volna.
3.nincs biznyitekunk hogy az intel megoldasaban beepitett szandekos gyengites van.
4.Fuggetlenul attol hogy menyire jo egy adott hw source, erdemes tobb forrast hasznalni, mert az ordog soha sem alszik. Murphy meg foleg.
5. az intel megoldas gyors, es ha cryto-hoz kell akkor hivatalosan megfelelel tobb tanustvanynak is a temaban.
6. Voltak egyes ugynoksegeknek megmozdulasi, hogy gyengitsenek biz eszkozok biztonsagan a szinfalak mogott es/vagy nyiltan
7. nem crypto celra (hacsak nincs valami specialsabb elvaras), az utasaitas teljesen jol hasznlahato

A mogottes matekkal, nagyon regen foglalkoztam, nem emlekszem, es nem is relevans, ha a fekete oltonyos gonosztevok altal bele ultett valamitol felunk.

Esetleg direct rosz algoritmust valasztottak volna, amire eddig meg senki nem mutatott ra ?

Lehet hogy en vagyok amator, de nem igy epittetnek backdoor-t a gyartokkal..


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"hivatalosan megfelelel tobb tanustvanynak is a temaban"

és ha elolvastad volna amit írtam, akkor tudhatnád, hogy sokszor már eleve ezeket a szabványokat és tanúsításokat manipulálják úgy, hogy számukra kedvező legyen

Volt regen valami crypto export restriction dolog..
Cserltek konstansokat, senki sem tudja miert..

Ha nem hasznlaunk HW rng-t, azt hiszem arra is volt valami demo, hogy a foleg
a megszakitasokon alapulo veletlen forrasok kiszamithatoak (kiszamithatova tehetok).

Ha semelyik rng forrasban sem bizhatunk,
bizhatunk -e, egy olyan eszkozben ami egy het meres utan is feher zajt dob ki,( meg minden egyeb adata jo),
mondjuk az NSA nekem kuldi a zajt szemlyesen fenypostan ;-) aztan en azt ateresztem egy sajat FPGA -ban implementalt szimetrikus titkositason (monjuk AES), a hasznalt kulcsot meg nem mondom meg az NSA -nak, ill. szabalyosan dobo kockaval kidobva ;-)

Gyenkgebb-ek lesznek -e az igy kapott veletlen szamaon alapulo kulcsaim, amit monduj AES (valasz mast ha ez mar eleve gonosz) -hez hasznalok, es vigan kuldozgetek vele adatokat az interneten keresztul. (init vec included, ha ujra hasznalt)

Szimatrikus HW titkositoval nehez nem eszrevehetoen, gonosz dolgot muvelni. Ebben egyet ertunk ? Teljesen determinisztikusnak kell leniuk.

A titkosittot feher zajom, eleg jo -e ? Feltetelezhetem -e, hogy mondjuk az NSA rejtett mintajat hasznalhatatlana teszi?


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Az AES algo-dhoz is kell RNG.

Nem kell, legalabbis magahoz EAS -hez, nem kell.

Azert adtam hozza az AES-t, egy RNG -hez, mert ha van olyan rosz tulajdonsaga az RNG -nek amit nem tudok eszlelene, de a fekete oltonyosok tudnak rola, akkor ez velhetoleg hasznalhatatlanna teszi szamukra.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Az init vektor értéke honnét jön? Úgy tudtam, hogy annál erősebb a titkosítása, minél jobb entrópiával tápláljuk meg. Nem hiszem hogy az asszimetrikussal keverném, mert használok AES-t az OpenSSL modullal és ott is van lehetőség véletlen init értékkel etetni.

AES(kockaval_kidobott_kulcs, RNG_src) -> bol vannak a tenylegesen hasznalt veletlen szamok, az inc vec is, ill. a kulcsok (tobbi) is ebbol titkosittot RNG -bol szarmazik.

Hetente ujra dobhatod a kulcsot, ha paranoid vagy;-)

Elso blikre mukdokepesnek tunik, de en nem ertek a lovakhoz.

Feltelezem hogy AES utan is jo kepessegu zajnak tunik, ha nem, akkor masik algo kell az AES helyett.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Neked is küldöm egy korábbi feladványomat. Nyílt forrású, így biztos megtalálod benne a backdoort:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/rnd.c.diff?r1=1.35&r2=1.36

> De fordítsuk meg a kérdést, elvégre az lenne a normális hozzáállás: van-e bizonyíték arra, hogy ezek a processzorban lévő megoldások biztonságosak?

Illeszkedésvizsgálat. Létező statisztikai terület.

naív vagy mint turul

Ha mernokokkrol van szo meg mindig naiv vagyok, de ha biztonsagi riogatasrol az default hamis( vagy eltulzott).


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ezért mondom, hogy Dunning–Kruger effektus. Nem értesz se a biztonsághoz, se a kriptográfiához, ellenben azt hiszed, hogy okosabb vagy a témában, mint az 1917 óta, napi szinten kifejezetten csak ezzel foglalkozó szervezet több ezer tehetséges szakértője együttvéve, akiknek sokkal nagyobb költségvetésük van a kutatásaikra, mint az egész civil szférának együttvéve és ráadásul minden publikus tanulmányt elolvasnak a témában, de nem adnak ki semmit, amikre ők rájönnek.

Ehhez a dologhoz: én azért arra is kíváncsi lennék, hogy a britek vagy az amerikaiak járnak előrébb. Lásd RSA vs Clifford Cocks.

Az NSA-nak is meg van a saját Clifford Cocksa más területeken, ahogy az Enigmát is tudta törni mindegyik egy idő után a második világháború alatt, csak ezt az információt nem feltétlenül osztották meg még egymással sem a szövetségesek.

Egyébként Whitfield Diffie pont egy NSA alkalmazottól tudta meg, hogy Clifford Cocks és James Ellis már korábban kitalálta a publikus kulcsú titkosítást a GCHQ berkein belül, csak a non-secret encryption nevet adták neki.

De hogy hány évvel járnak előbbre az néha nagyon egyszerű buktákból is kiderül. Pl. 1988-as (!) Morris féreg stack puffertúlcsordulási hibát használt ki a BSD finger daemon-ban, amelynek jelentőségét évekig nem fogta fel senki, csak 8 évvel később, az 1996-os "Smashing The Stack For Fun And Profit" Aleph One Phrack cikk után kezdtek el ezzel foglalkozni a hackerek a civil szférában.

Hogy honnan vette az ötletet már 1988-ban Robert Morris? Az apja (R.I.P.) az NSA vezető kutatója volt akkoriban...

Azért a buffer overflow már a 70-es években is ismert probléma volt ám.
http://csrc.nist.gov/publications/history/ande72.pdf
Ez eléggé sok problémát elemez.

Csak akkor még nem volt annyira elterjedt az internet és a tudásmegosztás, hogy nyilvánosan foglalkozzanak ezzel.
Na meg Aleph One kb. tutorialt adott, nem csak leírta a problémát. Ezért is lendült fel a dolog.

Ismert volt a buffer overflow mint programozási hiba, de exploitálási szemszögből nem volt a civil szférában köztudott a jelentősége, erről beszéltem. NSA viszont már nyilván ekkor is gőzerővel kutatta a témát, nem véletlenül jött az ötlet az NSA alkalmazott fiának, hogy ő is kipróbálja...

Az hogy az NSA hova fejlesztette a képességét ebben a témában, azt meg a Stuxnet is jól mutatja.

"azt hiszed, hogy okosabb vagy a témában, mint az 1917 óta, napi szinten kifejezetten csak ezzel foglalkozó szervezet több ezer tehetséges szakértője együttvéve"

Ez jó válasz, de vannak azért példák arra, hogy többezer profi évtizedeken át rosszul tudott valamit, és csak azért nem változtattak a nézetükön, mert az dogmává merevedett. Most hirtelen a Maxwell-démon jut eszembe példaként, de biztos van más is. Nem mondom, hogy a nagy költségvetésű, okos embereket foglalkoztató szervezetek mindig mindent rosszul tudnak, de az is biztos, hogy a kételkedés néha kifizetődő.

Mi van a Maxwell-démonnal, amit mindenki rosszul tudott?

Szilárd Leó 1929-ben bebizonyította, hogy a Maxwell-démon nem létezhet, és így a hőtan második főtétele sem sérül. A Wikipedia szerint 1998-ig kellett várni, hogy valakiknek feltűnjön, hogy Szilárd Leó bizonyítása a 2. főtételből indul ki, és ebből vezeti le, hogy a 2. főtétel érvényes. És egy pár évnek még el kellett telnie, hogy ezt mások is elfogadják, és egy 70 éves dogma kihaljon. Ma újra ott vagyunk, mint Maxwell idejében: a hőtan 2. főtétele tapasztalati törvény, és addig érvényes, amíg valahogy mást nem tapasztalunk.

Szerintem ez alma-körte. A fizikusokat és a biztonsági kutatókat nem érdemes így összehasonlítani. Utóbbiak a kételkedésből élnek... :)

1. A legtobb cryptoban alakalmazott dolog mogott olyon problema van, ami `nehez` -nek minosul, akkar tobb ezer eve megoldatlan (~ prim), vagy bizonyott hogy az megnengedett muvelet halmazzal(amit egy szamitogep alt tud.) nem lesz gyors megoldas ra.
2. A te baratidnak, olyan dolgot kene kitalalni amire senki mas "nem johet-ra", de ok tudjak. Ha barki mas ra hibazik, akkor ok is buknak, de oriasit, tenyleg megkockaztatnak ?
3. Ha riogatni akkarom a nepeket, akkor azt szoktam mondani, hogy quantum szamitogep megepitesenek 10 eve sem volt elvi akadaja, s egyebkent sem lenne mas haszna,
ugyhogy feltetelezhetoen erre jol el lehetne kolteni azt a penzt ;-)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Azért majd egyszer olvass utána azoknak az NSA backdooroknak és egyéb crypto és szabvány gyengítéseknek, amiket példának hoztam már 20 hozzászólással ezelőtt...

Aztán ha azokkal meg vagy, akkor mondjuk folytathatod a sort D. J. Bernstein és társainak elliptikus-görbéken alapuló kriptográfiai kutatásaival és az azokkal kapcsolatos véleményükkel, hogy "valamiért" a NIST (aka Amerikai Szabványügyi Intézet), az NSA Suite B, ANSSI, Brainpool és más szabványosított görbék nem biztonságosak.

Ha ezekkel is meg vagy, akkor utána gondolkozz el, hogy vajon a NOBUS műveletek, a Stuxnet és az egyéb kiderült "bukások" vajon mennyire számítanak számukra "óriási kockázatnak", valamint hogy egy bonyolult számítógépes rendszerben a "nehéz matek" önmagában elegendő-e a biztonsághoz és az erős titkosításhoz...

https://shop.gag.com/random.html

This page is insecure (broken HTTPS).
SHA-1 Certificate
The certificate for this site expires in 2017 or later, and the certificate chain contains a certificate signed using SHA-1.

:(

Amugy ennek mi ertelme van?

--
NetBSD - Simplicity is prerequisite for reliability

Hát az, hogy a véletlenszám-generátortól nagyban függ a kettős kulcsok biztonsága. Ha csak egy szűkebb részhalmazból merít a véletlenszám-generátor, és ez a szűkítés ismert, akkor sokkal gyorsabban fel lehet törni ssh kulcsokat, mint ami egyébként elvárható lenne. És (állítólag) ezt ki is használta a nagy testvér itt-ott, pontosabban: direkt béna véletlenszám-generátorokat építtetett be a széles körben elterjedt gépekbe, hogy ne kelljen sokat tökölni a bejutáshoz.

hiaba epitenek be barhova barmit, ugysem azt hasznaljak a (szerencsesebb) os-ek, akkor meg minek?

--
NetBSD - Simplicity is prerequisite for reliability

"A Chaoskey-t a Linux kernel a 4.1-es verzióról fogja támogatni. Használatához csak USB-re kell csatlakoztatni a Chaoskey-t és a driver automatikusan hozzáadja a hardver által biztosított entrópiát a kernel pool-hoz."

az eddigi forrasokkal mi baj volt?

van annyi sztohasztikus mukodes egy szamitogepben, hogy par perc alatt hetekre elegendo entropiat lehet gyujteni

--
NetBSD - Simplicity is prerequisite for reliability

Egy hiresebb pelda:
"Random Number Bug in Debian Linux"
https://www.schneier.com/blog/archives/2008/05/random_number_b.html
Vacak volt az openssl random szam generatora, ezert osszesen csak 2^15 kulonbozo ssh kulcsot tudott generalni. Ranezesre veletlenszerunek tuntek a 128bites kulcsok, de gyakorlatilag csak 32 ezer lehetoseg volt, ami miatt minden debian alapu (pl. ubuntu) rendszer is serulekeny volt.
(szerk.)

Umm ne hamisítsunk történelmet. :)

Debian maintainer műve volt. (bár kétségtelen, hogy kapott segítséget a dev listán. :))

Igen, ez a debian openssl RNG-jeben volt (ez szerintem a link cimeben is benne van), es igy atvette az ubuntu is. Ez csak egy pelda, hogy egy rossz RNG-nek milyen hatasa van.

Halhatatlan érdemei elismeréseképp (azóta?) hivatalos openssl developer lett Roeckx úr.

https://www.openssl.org/community/team.html

Személye már önmagában erős érv a LibreSSL használata mellett.

ez ellen ugyanugy nem vedett volna

--
NetBSD - Simplicity is prerequisite for reliability

Próbáltam összehasonlítást találni valamivel de nem találtam. Igaz, legfeljebb sebességre lehet könnyen mérést végezni.

Nem találtam infót, hogy akkor ez miből veszi a véletlent, fizikailag.

Pedig ott a noise source kapcsolasi rajza:
http://altusmetrum.org/ChaosKey/

Tranzisztor zaj.

Termikus zaj. A tranzisztor bázis-emitter letörési feszültsége nagyjából 7 V körül van. Amikor a letörés környékén van, áram indul a másik tranzisztor bázisába, az elkezd kinyitni, a kollektora alacsonyabb potenciálra kerül, s egyben megvédi a zajgenerátorként használt tranzisztor bázis-emitter átmenetét. Ha megnézed, ezen negatív visszacsatolás miatt mindig a letörés határhelyzetében fog ez üzemelni, s a kimenetén megjelenik a széles spektrumú fehérzaj. Ebből aztán mintát vesznek, majd A/D konverterrel digitális értékekké, ha úgy tetszik, számokká konvertálják.

Arról beszéltünk korábban néhányan, hogy rövid ideig kell mintát venni, különben kiátlagoljuk a zajt, ez tehát némi nehézséget jelent.

Szóval nyugalom, valóban véletlen lesz. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Érdekelne hogy mennyire véletlen? Hogyan tudják vizsgálni az entrópia minőségét? Nyilván minél jobb, annál jobban elrobban exponenciálisan - ha jól gondolom, vagyis vizsgálhatatlan. Vagy mégis?

Egy kicsit ismeretterjesztő jelleggel: Felállítanak egy/két entrópia poolt és ellenőrzik. Csak a megfelelő minőségű megy a rendszernek.
Az ellenőrzésre van módszer.

Lesz csoportos rendelés?

--------------------------------------------------------------------
http://www.kmooc.uni-obuda.hu/
http://www.memooc.hu/
https://www.safaribooksonline.com/

sub

[insert line here]
B.C. 3500 - DIY Vehicle / A.D. 30 - DIY Religion / A.D. 1991 - DIY OS

Szerintetek használható lesz ez valahogy korábbi kernelen is? Vagy megint nekiállhatok kernelt fordítani? Már el is felejetettem, hogy kell 8-)

Milyen verziókat használsz és mióta? :)

Most épp 3.16.0-4-amd64 (mindig ami debilyányban van)

Így 4.7.3 tájékán. Az egy több, mint 2 éves kernel.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem mondod! :) Hogy-hogynem, a kérdés pont erre vonatkozott.

Arra utaltam, hogy nem emiatt kellene már rég új kernel, hanem önmagában azért, mert cseppet sok víz lefolyt azóta a Dunán. Szóval a válasz egyértelmű igen. Ha jó okod van forrásból fordítani, akkor nosza, tedd meg! Valah magam is sokat fordítottam kernelt, de manapság semmi szükségem erre, minden megvan a disztribúcióhoz szállított binárisban, ami áltakában a legfrissebb vanillával szinkron verziójú.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Értem én, hogy régi, de minden simán fut fele, akkor meg minek babráljam? Ha valami működik, akkor nem kell háborgatni. A security pecsek jönnek rendszeresen. Szóval eddig semmi okom nem volt a váltásra. De ha vennék egy ilyent, akkor lenne. Úgy tűnik. Szóval ezért kérdeztem, hogy lehet-e, hogy korábbi kernellel is menni fog (valahogy), mert akkor nem kéne nekiállni forgatni. Mondjuk lehet, hogy lesz vmi backport testingből, és akkor se kell.

A kernel konfigurálása kicsit nyűgös lehet, ha nincs valami, amiből kiindulhatnál, de ezen felül ne mondd már, hogy akkora probléma a make && make install parancs kiadása. Olyan rég fordítottam, hogy már nem is emlékszem, kell-e a modules_install, vagy megcsinálja automatikusan.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Azért ez nem ilyen egyszerű ám :) A kernel közeli dolgok össze vannak lőve azért és sok esetben nagyon nem mindegy a kernel verzió a userland-hez képest.

Arról lenne szó, hogy saját hardware-hez saját fejlesztésű kernel modulok vannak fordítva?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem. Arra gondolok hogy egy ekkora kernel verzió ugrásnál bőven változhat az API, és a kernel közeli dolgok (nem tudom, systemd vagy akármi) azért nem bicikli meg pumpa egyszerűségűek - komoly rejtett hibák tudnak lenni egy ilyen komplex és 10-20 ezer csomagból álló ekoszisztemben.

Ebben van igazság. Akkor esetleg az oprendszer frissítése kernellel, glibc-vel, alkalmazásokkal együtt?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igen :)

Köszi a válaszokat. Közben utánanéztem (Khm...), hogy a jessie-backportsban van 4.6, szóval ha minden kötél szakad, akkor legfeljebb megpróbálom azzal.