Pingviini veeb

Meltdown ei pidavatki tegema midagi debiani kernelile halba!
https://www.memset.com/docs/server-secu ... wn-debian/

Juhuks, kui keegi ei teadnud, siis on veel üks Spectre'i-laadne leitud, variant 4 ehk "speculative store bypass". Mul on see juba lapitud, kuid selle jaoks oli jällegi vaja mikrokoodi (?) uuendust, kerneli uuendusest ei aita.
Kontrollida saad käsuga "cat /sys/devices/system/cpu/vulnerabilities/spec_store_bypass" (või "grep . /sys/devices/system/cpu/vulnerabilities/*" kõikide kontrolliks), mul näitab peale tänast mikrokoodi uuendust "Mitigation: Speculative Store Bypass disabled via prctl and seccomp"

Gomi kirjutas:Juhuks,
kui keegi ei teadnud, siis on veel üks Spectre'i-laadne leitud, variant
4 ehk "speculative store bypass". Mul on see juba lapitud, kuid selle
jaoks oli jällegi vaja mikrokoodi (?) uuendust, kerneli uuendusest ei
aita.
Kontrollida saad käsuga "cat
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass" (või "grep .
/sys/devices/system/cpu/vulnerabilities/*" kõikide kontrolliks), mul
näitab peale tänast mikrokoodi uuendust "Mitigation: Speculative Store
Bypass disabled via prctl and seccomp"

Jah, see 4 on rohkem javaskripti põhise rünnakuvõimalusega:
https://thehackernews.com/2018/05/fourt ... -flaw.html

ise kasutan firejaili rakendustes ja javascript on põhiliselt librejs kontrolli all.


OpenBSD lõpetab SMT (intel hyper-threading) toetuse, et välistada spectre bugi.
https://thehackernews.com/2018/06/openb ... ading.html

igasugune microsofti ja google jutt läheb kõrvast mööda, eriti kui peab paigaldama non-free microcode endale.
see on mu isiklik arvamus ja valik.

libre kirjutas:

Gomi kirjutas:Juhuks,
kui keegi ei teadnud, siis on veel üks Spectre'i-laadne leitud, variant
4 ehk "speculative store bypass". Mul on see juba lapitud, kuid selle
jaoks oli jällegi vaja mikrokoodi (?) uuendust, kerneli uuendusest ei
aita.
Kontrollida saad käsuga "cat
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass" (või "grep .
/sys/devices/system/cpu/vulnerabilities/*" kõikide kontrolliks), mul
näitab peale tänast mikrokoodi uuendust "Mitigation: Speculative Store
Bypass disabled via prctl and seccomp"

Jah, see 4 on rohkem javaskripti põhise rünnakuvõimalusega:
https://thehackernews.com/2018/05/fourt ... -flaw.html

ise kasutan firejaili rakendustes ja javascript on põhiliselt librejs kontrolli all.


OpenBSD lõpetab SMT (intel hyper-threading) toetuse, et välistada spectre bugi.
https://thehackernews.com/2018/06/openb ... ading.html

igasugune microsofti ja google jutt läheb kõrvast mööda, eriti kui peab paigaldama non-free microcode endale.
see on mu isiklik arvamus ja valik.

Microsoft ning Google on sulle ikka "silmaklapid ette pannud" kuna Linuxi maailmas uuendatakse neid Mikrokoode, automaatselt, uuenduste paettides ja keegi ei küsi arvutiomaniku käest midagi.
Tänases Ubuntu 18.10-e uuenduspakis oli taas Mikrokoodi uuendus automaatselt kenasti sees olemas.

Canonical Releases AMD Microcode Updates for All Ubuntu Users to Fix Spectre V2
Available for Ubuntu 18.04 LTS, 17.10, 16.04 LTS & 14.04 LTS

https://news.softpedia.com/news/canonic ... 1669.shtml

vooler3 kirjutas: Microsoft ning Google on sulle ikka "silmaklapid ette pannud" kuna Linuxi maailmas uuendatakse neid Mikrokoode, automaatselt, uuenduste paettides ja keegi ei küsi arvutiomaniku käest midagi.
Tänases Ubuntu 18.10-e uuenduspakis oli taas Mikrokoodi uuendus automaatselt kenasti sees olemas.

Canonical Releases AMD Microcode Updates for All Ubuntu Users to Fix Spectre V2
Available for Ubuntu 18.04 LTS, 17.10, 16.04 LTS & 14.04 LTS

https://news.softpedia.com/news/canonic ... 1669.shtml

Mul on debian 9 oma arvutis ja ma vaatan, et microcode asub non-free repositooriumis, mis on mul eemaldatud:
https://packages.debian.org/stretch-bac ... -microcode
https://packages.debian.org/stretch-bac ... -microcode

libre kirjutas:

Gomi kirjutas:Juhuks,
kui keegi ei teadnud, siis on veel üks Spectre'i-laadne leitud, variant
4 ehk "speculative store bypass". Mul on see juba lapitud, kuid selle
jaoks oli jällegi vaja mikrokoodi (?) uuendust, kerneli uuendusest ei
aita.
Kontrollida saad käsuga "cat
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass" (või "grep .
/sys/devices/system/cpu/vulnerabilities/*" kõikide kontrolliks), mul
näitab peale tänast mikrokoodi uuendust "Mitigation: Speculative Store
Bypass disabled via prctl and seccomp"

Jah, see 4 on rohkem javaskripti põhise rünnakuvõimalusega:
https://thehackernews.com/2018/05/fourt ... -flaw.html

ise kasutan firejaili rakendustes ja javascript on põhiliselt librejs kontrolli all.


OpenBSD lõpetab SMT (intel hyper-threading) toetuse, et välistada spectre bugi.
https://thehackernews.com/2018/06/openb ... ading.html

igasugune microsofti ja google jutt läheb kõrvast mööda, eriti kui peab paigaldama non-free microcode endale.
see on mu isiklik arvamus ja valik.

Mikrokood on protsessoril tööks vajalik nii kui nii, see, et sina uuemat versiooni peale ei lae, ei tähenda, et sul seda pole või veel et see on sul kuidagimoodi vabam. Ma ei tea ka, kui väga Firejail selliste pigem riistvara-põhiste rünnakute vastu aitab.

Aga ega mina ei saa takistada sind pea liiva alla peitmast lootuses, et see sind kuidagi aitab.

Gomi kirjutas: Mikrokood on protsessoril tööks vajalik nii kui nii, see, et sina uuemat versiooni peale ei lae, ei tähenda, et sul seda pole või veel et see on sul kuidagimoodi vabam. Ma ei tea ka, kui väga Firejail selliste pigem riistvara-põhiste rünnakute vastu aitab.

Aga ega mina ei saa takistada sind pea liiva alla peitmast lootuses, et see sind kuidagi aitab.

Kuna mul on kaks kernelit, üks on 4.9 debian ja teine 4.9-gnu:
linux 4.9.109-gnu.pae #1 SMP Sun Jun 17 06:04:57 UTC 2018 i686 GNU/Linux

mõlematel on üldine microcode moodul, mille source code on loetav, intel-microcode või amd-microcode on loetamatu source koodina ja kuulub ikka non-free alla.

Pea liiva alla peidavad ikka need, kes ei näe ka source e. lähtekoodi mitte üldsegi.


Niikaua pean ikka gpl litsentsi all olevaid mooduleid kasutama..


( firejail lülitab programmi jaoks üldse kerneli paljud osad välja või keelab need ära, mida ei ole vaja. )


FSF pole veel käsku andnud, et peab non-free microcode kasutama....
DEBIAN aga küll oma kodukal käsib non-free mikrokoodi kasutada, mida mina eitan.

libre kirjutas:

Gomi kirjutas: Mikrokood on protsessoril tööks vajalik nii kui nii, see, et sina uuemat versiooni peale ei lae, ei tähenda, et sul seda pole või veel et see on sul kuidagimoodi vabam. Ma ei tea ka, kui väga Firejail selliste pigem riistvara-põhiste rünnakute vastu aitab.

Aga ega mina ei saa takistada sind pea liiva alla peitmast lootuses, et see sind kuidagi aitab.

Kuna mul on kaks kernelit, üks on 4.9 debian ja teine 4.9-gnu:
linux 4.9.109-gnu.pae #1 SMP Sun Jun 17 06:04:57 UTC 2018 i686 GNU/Linux

mõlematel on üldine microcode moodul, mille source code on loetav, intel-microcode või amd-microcode on loetamatu source koodina ja kuulub ikka non-free alla.

Pea liiva alla peidavad ikka need, kes ei näe ka source e. lähtekoodi mitte üldsegi.


Niikaua pean ikka gpl litsentsi all olevaid mooduleid kasutama..


( firejail lülitab programmi jaoks üldse kerneli paljud osad välja või keelab need ära, mida ei ole vaja. )


FSF pole veel käsku andnud, et peab non-free microcode kasutama....
DEBIAN aga küll oma kodukal käsib non-free mikrokoodi kasutada, mida mina eitan.

Kui sina ei lae uuemat mikrokoodi, siis jääb peale see, mis protsessoriga kaasas on või mille emaplaat ise peale laeb. See on protsessori firmware, sul arvuti lihtsalt ei töötaks selleta. Selle alikkoodi sul eeldatavasti pole ning see on samuti Inteli allkirja saanud.
Selgita mulle palun, kuidas vana mittevabavaralise, lisaks veel ülimalt vigase mikrokoodi peal hoidmine on kasulikum võrreldes uue, täpselt sama mittevabavaralise, kuid mitte nii vigase mikrokoodi peale laadimisest. Nii ideoloogiliselt kui praktiliselt küljelt tundub see mulle mõttevabana.

Gomi kirjutas: Kui sina ei lae uuemat mikrokoodi, siis jääb peale see, mis protsessoriga kaasas on või mille emaplaat ise peale laeb. See on protsessori firmware, sul arvuti lihtsalt ei töötaks selleta. Selle alikkoodi sul eeldatavasti pole ning see on samuti Inteli allkirja saanud.
Selgita mulle palun, kuidas vana mittevabavaralise, lisaks veel ülimalt vigase mikrokoodi peal hoidmine on kasulikum võrreldes uue, täpselt sama mittevabavaralise, kuid mitte nii vigase mikrokoodi peale laadimisest. Nii ideoloogiliselt kui praktiliselt küljelt tundub see mulle mõttevabana.

Lepime siis nii kokku, et igal seadmel on oma mikrokood, mille kaudu asi toimib. Draiverid on siis need, mis oskavad paremini riistvara enda mikrokoodi käsitleda. Emaplaadil on oma mikrokood, cpu-l, kõvakettal .jne

Kui ma saan vaba draiveriga ja kõigi vaba programmidega, mis oskavad firma riistvara mikrokoodi käsitleda, siis on OK.

Probleem ongi selles, et tänu uuematele BIOS/UEFI ja CPU firmwaredele, mille haardeulatus on suurenenud, ei julge ma kinniseid mooduleid, firmwaresi, update-draivereid mikrokoodide jaoks uuendada, eriti kui mul ei ole librebooti:
https://hardware.slashdot.org/story/15/ ... mt-removed

Samas täpsem info mikrokoodidest ja testidest siin:
https://www.dcddcc.com/docs/2014_paper_microcode.pdf

Ma nii spetsiifiliselt asjast aru ei saa, kuid lohutuselks pean ütlema, et ka firefox suudab nüüd toime tulla spectre ja meltdowni ajarünnakutega.

Seda riistvaralist CPU bugi saab programmidega manipuleerida paremuse suunas nagu ka halbade programmidega halvemuse suunas.

Minu jaoks on hea kui programmi lähtekoodi saab lugeda , kuidas ta seda riistvara käsitleda suudab.

hea ju kui kolmekäigulist jalgratast saab ka kahekäiguga kasutada kui vaba programmi kolmas käik ei sega ja oskab selle välja lülitada.



Minu jaoks on tähtis, kuidas vaba tarkvara põhiprogrammid suudavad hakkama saada riistvara mikrokoodide, draiveritega. CPU jooksutamist kasutavad programmid, kerneli abiga ja kernel draiverite ja moodulite abiga - jällegi tuleb 3 käigulisel 2 käigu võimalus kui vaja....

LIsa: MUL on vana bios ja Pentium DualCore T4200, mis ei ole i3-i7 veel.
Pealegi püüan kasutada turvakaste ja javaskripti vabavorme (LibreJS 7 ver. näiteks firefox 60 peal töötab juba päris kiiresti ja hästi.)

libre kirjutas: Minu jaoks on hea kui programmi lähtekoodi saab lugeda , kuidas ta seda riistvara käsitleda suudab.

Tahad öelda, et sa saad tõesti koodist aru?

libre kirjutas:Lepime siis nii kokku, et igal seadmel on oma mikrokood, mille kaudu asi toimib.

Aru olen saanud küll (ning edasine uurimine on seda kinnitanud), et "mikrokood" viitab vaid CPU-de firmware'ile, GPU-del, võrguseadetel, audiokaartidel jne. on lihtsalt firmware. Kuid see vist nii tähtis pole.

Draiverid on siis need, mis oskavad paremini riistvara enda mikrokoodi käsitleda. Emaplaadil on oma mikrokood, cpu-l, kõvakettal .jne

Kui ma saan vaba draiveriga ja kõigi vaba programmidega, mis oskavad firma riistvara mikrokoodi käsitleda, siis on OK.

Kood, mis laeb mikrokoodi, on täiesti avalik. Linuxi allikkoodis arch/x86/kernel/cpu/microcode/intel.c

Probleem ongi selles, et tänu uuematele BIOS/UEFI ja CPU firmwaredele, mille haardeulatus on suurenenud, ei julge ma kinniseid mooduleid, firmwaresi, update-draivereid mikrokoodide jaoks uuendada, eriti kui mul ei ole librebooti:
https://hardware.slashdot.org/story/15/ ... mt-removed

Kui sa ei usalda firmware'i, siis sa vist ei usalda tootjat üldiselt ning ma ei näe ka, et sa mingit praktilist lahendust sellele annaksid. Nad võivad toppida selle sama mittevaba firmware'i kuskile ROMile ning sina lihtsameelselt näed, et see töötab ning ei pea mingit mittevaba tarkvara alla laadima. Uuendada seda muidugi ei saa, sest on ROMil. Ning kui tootja tahaks sulle pekki keerata, siis pole sul midagi teha, kui sa juhtumisi mõni valitsus või Google/Microsoft/Apple/sellelaadne firma ei ole.

Samas täpsem info mikrokoodidest ja testidest siin:
https://www.dcddcc.com/docs/2014_paper_microcode.pdf

Kas sa seda ise lugesid või toppisid selle niisama siia...?

Ma nii spetsiifiliselt asjast aru ei saa, kuid lohutuselks pean ütlema, et ka firefox suudab nüüd toime tulla spectre ja meltdowni ajarünnakutega.

Seda riistvaralist CPU bugi saab programmidega manipuleerida paremuse suunas nagu ka halbade programmidega halvemuse suunas.

Ee... Misasja?

Minu jaoks on hea kui programmi lähtekoodi saab lugeda , kuidas ta seda riistvara käsitleda suudab.

Huvitav vaid, kas sa seda mõistaksid... (Vean ka kihla, et see on enamuses, kui mitte täies ulatuses midagi ASM-laadset)

hea ju kui kolmekäigulist jalgratast saab ka kahekäiguga kasutada kui vaba programmi kolmas käik ei sega ja oskab selle välja lülitada.

Ee... Mida?

Minu jaoks on tähtis, kuidas vaba tarkvara põhiprogrammid suudavad hakkama saada riistvara mikrokoodide, draiveritega. CPU jooksutamist kasutavad programmid, kerneli abiga ja kernel draiverite ja moodulite abiga - jällegi tuleb 3 käigulisel 2 käigu võimalus kui vaja....

Uuema mikrokoodi laadimine on ikkagi vabavaraline kood ning mikrokood on laetud nii kui nii... Kordan end, mis eelist annab sulle vana, katkise, täpselt sama mittevaba mikrokoodi jooksutamine?

LIsa: MUL on vana bios ja Pentium DualCore T4200, mis ei ole i3-i7 veel.
Pealegi püüan kasutada turvakaste ja javaskripti vabavorme (LibreJS 7 ver. näiteks firefox 60 peal töötab juba päris kiiresti ja hästi.)

Gomi kirjutas:
Kood,
mis laeb mikrokoodi, on täiesti avalik. Linuxi allikkoodis
arch/x86/kernel/cpu/microcode/intel.c

Jah, on C keeles lähtekood ja ilusasti loetav, kuid linux-libre sources
on seal kolmes kohas (DEBLOBBED) sõna sees s.t ka koodi on pisut
muudetud.

dmesg näitab kõikide non-free draiverite kohta:
Firmware file "/*(DEBLOBBED)*/"

JA MIKS MA kasutan veel 2008 aasta BIOSE flashi tarkvara? Ja Inteli 10 aasta vanust mikrokoodi?
Sest 2018 aastaks on non-free arendajad nii nutikaks läinud, et kirjutavad ei mida veel sisse...

https://www.gnu.org/proprietary/proprie ... doors.html

libre kirjutas:

Gomi kirjutas:
Kood,
mis laeb mikrokoodi, on täiesti avalik. Linuxi allikkoodis
arch/x86/kernel/cpu/microcode/intel.c

Jah, on C keeles lähtekood ja ilusasti loetav, kuid linux-libre sources
on seal kolmes kohas (DEBLOBBED) sõna sees s.t ka koodi on pisut
muudetud.

dmesg näitab kõikide non-free draiverite kohta:
Firmware file "/*(DEBLOBBED)*/"

JA MIKS MA kasutan veel 2008 aasta BIOSE flashi tarkvara? Ja Inteli 10 aasta vanust mikrokoodi?
Sest 2018 aastaks on non-free arendajad nii nutikaks läinud, et kirjutavad ei mida veel sisse...

https://www.gnu.org/proprietary/proprie ... doors.html

Vaadates skripti ennast on selgelt näha, et see vaid teeb mikrokoodi laadimise võimatuks sõnumiga "disabled non-Free firmware-loading machinery", see ei ütle kuidagimoodi, et mikrokoodi laadimine iseenesest on mittevabavaraline. Ning, kordan end, kuid kui sul polekski mikrokoodi kuskil, ei saaks sa arvutit käimagi.
Olgugi siis, sinu elu, sinu valikud, kui arvad, et pea liiva all hoidmine sind kaitseb, siis anna aga käia.

githubis on siis uus skript üleval, mis näitab ka 3a ja 4 ära:
mul näitab nii linux-libre kui ka debian 4.9 kernel, et 3 ja 3a ja 4 on VULNERABLE!

Seejärel eemaldasin linux-libre kerneli ja pagialdasin intel-microcode backports non-free repost.
Peale debiani kerneli käivitamist näitab dmesg:

#dmesg | grep micro
[ 0.000000] microcode: microcode updated early to revision 0xa0b, date = 2010-09-28
[ 1.143794] microcode: sig=0x1067a, pf=0x80, revision=0xa0b
[ 1.143865] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

ainuke muutus on et 2010-09-28 microkood töötab juures..

Minu arvutile ei ole veel mikrokoodil erilist midagi öelda ja skript näitab ikka et
3, 3a ja 4 on VULNERABLE!

Selle lappimisega on vist nii, et vanematele prosedele seda parandust ei tehtagi. HV foorumis teema ja seal ühes viidatud lingil oli nimekiri,millised prosed saavad paranduse.

siin protsessorite microkoodide versioonide nimekiri
https://www.intel.com/content/dam/www/p ... idance.pdf

Jälle uuendatud.
Lisaks on foreshadow test ja kontrollib ka Hyper-Threading (SMT) värki.