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/fourth-critical-spectre-cpu-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/openbsd-hyper-threading.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/canonical-releases-amd-microcode-update-for-all-ubuntu-users-to-fix-spectre-v2-521669.shtml

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/fourth-critical-spectre-cpu-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/openbsd-hyper-threading.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.

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.

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

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/01/29/2241214/fsf-endorsed-libreboot-x200-laptop-comes-with-intels-amt-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.)

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

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/proprietary-back-doors.html