Intelin prosessoreista on löytynyt merkittävä suunnitteluvirhe ja tietoturvauhka, joka vaatii käyttöjärjestelmiltä kernelitason päivitystä. Vaikka ongelma havaittiin vasta nyt, se on olemassa kaikissa Intelin moderneissa prosessoreissa.
Intelin prosessoreista löytyvä bugi aiheuttaa parhaillaan päänvaivaa kehittäjille. Rautatason ongelma on niin vakava, ettei sitä voida tämänhetkisten tietojen mukaan korjata esimerkiksi mikrokoodipäivityksellä, vaan se vaatii käyttöjärjestelmien päivityksen kernelitasolla ongelman kiertämiseksi.
Toistaiseksi ongelman tarkka kuvaus on vielä salaista tietoa, mutta io-techin toimituksen tietojen mukaan kyse on tavasta, jolla Intelin prosessorit käsittelevät virtuaalimuistia, mikä voi johtaa suojatun kernelimuistin tietojen vuotamiseen käytännössä minkä tahansa ohjelman avustuksella. Ongelman korjaukseksi käyttöjärjestelmien on otettava käyttöön Kernel Page Table Isolation -ominaisuus eli PTI, joka eristää kernelimuistin täysin käyttäjätason muistiavaruudesta. Korjaus on näennäisesti ehkä yksinkertaisen kuuloinen, mutta todellisuudessa se on merkittävä muutos ja voi hidastaa useita toimintoja huomattavasti. Jotain korjauksen luonteesta kertonee myös se, että The Registerin mukaan Linux-kehittäjät kutsuivat bugin korjausta yhdessä välissä nimellä Forcefully Unmap Complete Kernel With Interrupt Trampolines, eli lyhyesti FUCKWIT.
Vaikka ongelman tarkka kuvaus on edelleen salainen, AMD:n Tom Lendackyn viesti Linux-kernelin kehittäjien mailiketjuun vihjaa, että ongelma olisi tavassa jolla Intelin prosessorit ennakoivat tulevia tehtäviä nopeuttaakseen toimintaansa. Ilmeisesti näissä tapauksissa saatetaan jättää turvatarkistukset väliin, jolloin ennakkoon suoritettava komento saattaa päästä lukemaan esimerkiksi kernelimuistia vaikkei sillä pitäisi olla mitään asiaa korkeampia oikeuksia vaativiin muistiosoitteisiin. AMD:n prosessoreissa tätä ei pääse tapahtumaan, vaan ne estävät esimerkiksi käyttäjätason prosessien pääsyn korkeampia oikeuksia vaativiin tietoihin myös ennakoivan suorituksen osalta. Samaan viittaa myös tietoturvaekspertti Anders Foghin aiemmat testit asian tiimoilta.
Linux-puolella on saatu jo julki ensimmäinen päivitys, jonka on tarkoitus korjata ongelma Intelin raudalla. Ongelmattomasta päivityksestä ei voida puhua, sillä tällä hetkellä päivitys pakottaa PTI:n käyttöön myös AMD:n prosessoreilla, vaikkei ongelma koske niitä lainkaan. Tämän myötä suorituskykyongelmat koskevat kyseisellä päivityksellä myös AMD:n prosessoreita.
Korjaus vaikuttaa kokoonpanon suorituskykyyn eniten raskaissa I/O-tehtävissä eli kotikäyttäjien ei tarvinne olla niistä huolissaan. Phoronixin alustavien testien mukaan Linux-alustalla esimerkiksi pelisuorituskyvyssä ei ole nähty eroa ennen ja jälkeen päivityksen.
Datakeskuksissa tilanne on kuitenkin toinen ja The Registerin raportin mukaan keskimääräinen suorituskykytappio synteettisissä testeissä saattaisi olla jopa 5 – 30 prosenttia, mutta sivusto ei tarjoa väitteelle lähdettä tai todisteita. AnandTechin Ian Cutressin mukaan ensimmäiset todelliset tulokset puhuvat alle puolen prosentin erosta. Phoronixin ajamat tiedostojärjestelmää rasittavat testit puhuvat myös sen puolesta, että tietyissä tehtävissä erot voivat olla erittäin suuria.
Windows-puolella ainakin alustavan päivityksen julkaisun odotetaan tapahtuvan seuraavan Patch Tuesdayn yhteydessä eli vajaan viikon kuluttua 9. tammikuuta. Myös Applen macOS-käyttöjärjestelmä tulee tarvitsemaan päivityksen, mutta sen aikataulusta ei ole toistaiseksi tietoa.
Lähteet: The Register & Reddit
Tarkat yksityisikohdat tästä haavoittuvuuduesta on tarkoituksella jätetty julkaisematta, jotta järjestelmät saadaan päivitettyä, mutta jonkin verran tästä kuitenkin tiedetään.
Valitettavasti myös mutua ja FUDia on liikkeellä aika paljon.
Tämä IO-techin artikkeli onnistui nimenomaan kertomaan tiedossa olevat faktat aika hyvin, sen sijaan että olisi lähtenyt pelottelemaan ja suurentelemaan lukuja kuten esim. monet kommentoijat täällä.
Se jossain mainittu 30% luku oli yksittäinen "worst case real-world benchmark" joka teki todella paljon enemmän kernelkutsuja kuin esim. työpöytäsoftat tekee.
Peruskäyttäjän työpöytäsoftilla suorituskykyvaikutus jää hyvin pieneksi.
Sen sijaan palvelinsoftillla jotka tekee paljon IOta ollaan helposti 10% paremmalla puolella, mikä muuttaa selvästi EPYCin ja Xeonin välistä kilpailuasetelmaa.
Ongelma tässä patchissä vaan on se, että siinä on täysin unohdettu VIAn , Transmetan yms. suorittimet.
En minä näe tuossa ongelmaa. Muiden suoritinvalmistajien prosessorit edustavat pyöristykseen häviävää prosenttimäärää markkinoista eikä kukaan ole todistanut niitä turvalliseksi tuon bugin tai muidenkaan suhteen.
Tuossa koodissa on selvä virhe. Tyyppi luulee, että yhteenlaskun viive on 3 kellojaksoa, vaikka se on todellisuudessa yksi.
Lisäksi prosessorista loppuu ROBit ja/tai fyysiset rekisterit kesken kun näitä tehdään 300 peräkkäin.
Näiden syiden yhteisvaikutuksesta tuossa tulee vain ehkä n. 170 kellojakson viive paikkaan, jossa tarvittaisiin >400 tai >800 kellojakson viive, jotta explot toimisi.
Tämä voi olla syy, miksei saanut exploittia toimimaan
spekulaatiota:
Eli, voi olla, että kyse on tuosta tuossa postauksessa esitetystä jutusta. Ja joku muu on tuon lukenut, huomannut koodissa olevan virheen, korjannut sen (vaihtanut esim. viiveenä yhteenlaskut jakolaksuiksi tms.), ja saanut sillä exploitin toimimaan. Ja jättänyt korjatun koodin julkaisematta, sen sijaan ottanut yhteyttä Inteliin, AMDhen, microsoftiin ja linux-kehittäjiin, että korjatkaa.
Tai sitten tyyppi itse on myöhemmin tajunnut virheensä, korjannut koodinsa, saanut exploitin toimimaan, ottanut inteliin, AMDhen, microsoftiin ja linux-kehittäjiin yhteyttä ja jättänyt postaamatta exploitin korjattua versiota ennen kuin patchit on ulkona.
Tässä on tuo AMD-kehittäjän alk.per. patch, jota ei tuollaisenaan syystä tai toisesta ole vielä hyväksytty.
vai että FUCKWIT-gate. Ainakin nähdään taas että jenkit rakastavat anagrammejaan sekä onelinereitaan.
nähtävästi lopputuleman ollessa kotikäyttäjälle ja pelaajalle yks hailee, onhan tämä hieno alku vuodelle draaman ja monokkelimiesten osakekauppain merkeissä:geek:
Offtopic:
En usko tuon olevan mikään syy palautuksille. Prosessorihan on ihan yhtä nopea kuin aikaisemmin. Se etteivät päivitetyt ohjelmat toimi yhtä nopeasti kuin aiemmin on ihan normaalia.
Ihan oikeinhan tuo menee. Intel on tehnyt itse täysin samaa menneisyydessä. Eli prosessori = Intel, valitse tappiinsa optimoitu koodipolku. Prosessori ei Intel = laita paska ja optimoimaton koodipolku suoritukseen.
Offtopic:
En usko tuon olevan mikään syy palautuksille. Prosessorihan on ihan yhtä nopea kuin aikaisemmin. Se etteivät päivitetyt ohjelmat toimi yhtä nopeasti kuin aiemmin on ihan normaalia.
Ihan oikeinhan tuo menee. Intel on tehnyt itse täysin samaa menneisyydessä. Eli prosessori = Intel, valitse tappiinsa optimoitu koodipolku. Prosessori ei Intel = laita paska ja optimoimaton koodipolku suoritukseen.
Oikein toimivalla ajoympäristöllä Javascriptillä on mahdotonta saada aikaan muistiviittausta, joka viittaa osoitteeseen, jossa ei ole mitään ohjelman dataa koskaan ollutkaan.
Eli jos tässä on kyse tuosta spekuloidusta latauksesta kernelin muistiosoitteeseen, tätä on mahdotonta hyödyntää javascriptin kautta.
Rowhammer onnistuu javascriptistä, koska javascriptissä voi alloikoida ison taulukon ja tehdä sen sisälle paljon laillisia muistinosoituksia.
Peruskäytössä eroa tuskin joo huomaa, mutta sit ku tulee puheeseen tyyliin videoenkoodaus taikka montaa ydintä käyttävät pelit, ni siinä huomaa eroa. Tosin, isoin robleemahan on tottakai tietoturva, siitä ei koskaan saisi tinkiä.
Videoenkoodauksessa nimenomaan ei huomaa, koska siinä tehdään hyvin pieni määrä IO-operaatioita suhteessa laskennan määrän.
Mielenkiintoista nähdä miten virtualisointialustoja kauppaavat Vmware, Oracle ja Microsoft suhtautuvat asiaan ja mitä korjauksia tulee. Ja ennenkaikkea – miten vaikuttaa suorituskykyyn. Hlökohtainen veikkaus on että eniten performance-hittiä ottaa Vmware 🙂
Eli nopeasti laskien jos nyt on käytössä 5GHz kellotettu Intelin prosessori se päivityksen jälkeen vastaa noin 4.75-3.5GHz samanlaista prosessoria niissä ohjelmissa/peleissä jne. missä tuo ongelma ilmenee. JOS esim. näytönohjain tms. ei ole se jarruttava tekijä. (5-30%)
Ei kait tässä sen kummempaa kuin, että odottelemme koetuloksia ennen ja jälkeen korjauspäivityksen.
Lasket täysin rikkinäisillä luvuilla.
Peleillä se hidastuvuusu on luokkaa 0.5%, ei 5-30%.
Videopakkauksessa Phoronixin testissä erot osuvat virhemarginaalin sisään sekä FFMPEG:in että x264:n osalta. Ja noissa ei tosiaan muutenkaan pitäisi tulla takkiin, kun videopakkauksessa ei kerneliä tarvita.
Synteettinen pakkaustesti ei ole videoeditointia.
Tahtoisin nähdä sen kun editoidaan videota oikeasti, tai vaikka lennosta livestreamia useampaa HDMI kaapparikorttia käyttäen..
Käsittääkseni tuo 30% oli myös synteettinen eikä real world -testi, eikä ole edes etäisesti lähellä worst casea synteettisissä testeissä (Phoronixin tiedostojärjestelmätestissä Coffee Lake otti yli 50% hittiä)
Lähdekoodia tyyppi ei vielä julkaissut.
Mielenkiintoinen yksityiskohta on sanat "no page faults required".
spekulaatiota:
Voi olla että "no page faults required" on toteutettu sillä, että muistiaccessi kiellettyyn osoitteeseen tehdään väärin ennustetussa haarautumisessa, eli siis if-blokissa jonne koodin ei pitäisi mennä. Tämä todennäköisesti taas tarkoittaa, että koodissa pitää nähdä jonkin verran vaivaa sen haarautumisenennustuksen huijaamiseen
Ei pitäisi siltikään mennä kernelille kovin paljoa tavaraa. Laiteajurit ovat pitkälti userspace-kamaa nykyään. Ja myös ne nopeat laiteajurit, kuten DPDK ja SPDK.
Ja täysin virheettömästi toimiva JS-ajoympäristö on? Noh, vitsit vitseinä, eikä ongelman ydin tässä tapauksessa ei ole JavaScriptin mahdollinen heikkous tai soveltuvuus hyökkäykseen. Mutta onhan ainakin WebKit tunnetusti ollut hyvä alusta erilaisille jailbreakeille. Sinänsä hauska yksityiskohta, että pleikka nelonen, mikä on murrettu nimenomaan WebKit/JavaScript ROP-koodilla, on sisuksiltaan AMD.
Myös VM maailmassa? Myönnettäköön etten aihetta kauhean hyvin tunne.
Jos se javascript-ajoympäristö sisältää sellaisen bugin, että sillä voi tehdä javascriptistä laittomia muistiaccesseja, sitten sen tietoturva on joka tapauksessa vakavasti pilalla. Ja se pyritään korjaamaan ASAP jos siitä sellainen aukko löytyy.
Saksalaiset Computerbase ja Hardwareluxx ajaneet testejä:
Windows Build 1709 vs. Build 17063
Intel: Details und Benchmarks zur Sicherheitslücke in allen CPUs
Intel kämpft mit schwerer Sicherheitslücke im Prozessor-Design (Update: Windows-Benchmarks) – Hardwareluxx
Näistä siis tuo 1709 on Fall Creators Update ja tuo 17063 uudempi KPTI-korjauksella varustettu Insider Preview.
ohhoh! Nytpä oli pommi, seuraillaan… (onkohan sopimus sakkoa paukkumassa?)
inteliltä taitaa sulaa nyt isosti valuuttaa tähän sotkuun, kun pääsi julkiseksi ja isommin jos eivät keksi muutakuin purkkaa korjatakseen.
Kyllähän nuo peleissäkin näkyvät olevan virhemarginaalin ulkopuolella eli kyllä tässä on tosi kyseessä. Ja nuo ovat simppelit FPS-testit, saa nähdä tuleeko myös stutterointia, latausaikojen nousua yms.
Eiköhän sieltä vähintään joukkokanne jenkeissä ole luvassa suorituskyvyn ja tietoturvan vuoksi.
Avg fps peleissä ei juurikaan mitään mitään kerro, mielenkiinnolla odotan mitä frametimet sanoo.
Linuxillahan käsittääkseni sama suorituskykyhitti tuli myös MADin laskimille kernelikorjauksen jälkeen. Onko jo tiedossa, että miten Windows hoitaa homman? Kärsiikö myös MAD nuo samat laskut suorituskyvyssä?
Jos kyse on side-channel-hyökkäyksestä, niin ei.
Side-channel-haavoittuvuus ei ole bugi, vaan ominaisuus. Prosessori toimii softan näkökulmasta täysin kuin sen pitäisi.
Ja se että AMD on tälle immuuni, kyse on enemmän siitä että AMDllä kävi hyvä tuuri, ettei AMD ehtinyt toteuttaa yhtä aggressiivista muistioperaatioiden uudelleenjärjestelyä tai spekulatiivista suoritusta, ei siitä että AMD olisi osannut ja Intel olisi mokannut.
Kyseessä on vähän saman tason juttu, kuin että naapurisi on perustanut leipomon, joka tekee uusia todella hyvänmakuisia kakkuja, ja sinä haluat vakoilla, mitä ainesosia siinä reseptissä on. Naapurisi on kuitenkin huolehtinut tietoturvastaan, etkä pääse sitä mitenkään suoraan vakoilemaan.
Huomaat kuitenkin, että lähikauppasi (joka ei suoraan suostu kertomaan, mitä muille asiakkaille myy) on suurentanut selvästi hyllyään, jossa säilöö kardemummaa, ja kardemumma on kaupasta aina joko lopussa, tai sitä on kaupassa todella paljon, hyvin tuoreella päivämäärällä.
Tästä voi päätellä, että naapurisi salaisessa reseptissä käytetään kardemummaa.
Spekulaatiosi kaltainen hyökkäys kuvailtiin juuri jossakin analyysissä.
Ja myöhempään kommenttiisi, että amd on turvallinen vahingossa.
Kyllä nyt olet väärässä. Amd nimenomaisesti ilmoitti että edes spekuloduissa referensseissä amd on estänyt alemman tason oikeudet omaavan koodin accessin ylemmän tason dataan.
Tuli, mutta AMD korjasi virheen nopeasti. Eli todellisuudessa ei tullut.
Eiköhän sama käy winkkarin puolella. Intel yrittää pakottaa korjauksensa kaikkiin, mutta AMD ei halua sitä omille prossuilleen kun se on turhaa.
Toivotaan että tämä myös pitää paikkaansa. 🙂
Entäs sellaset pelit jotka lukee tyyliin kaiken kiintolevyiltä? The Secret World sellanen että jos magneettikiekolta koittaa pelaa niin peli lagaa niin tajuttomasti.
Perse, eikö enää voi sanoa kuinka intelin prosessoreissa on fyysinen tietoturva haavoittuvuus, kun se on nyt koko maailman tiedossa. Tosin ei kukaan uskonut aiemminkaan ja hullun maine tuli nopiaan. :think:
50-70MB/s lukunopeuden hidastuminen näyttää uskomattomalta, pakko olla kyllä joku virhe.. :jd:
Side channel hyökkäyksen määritelmästä olen liki samaa mieltä, mutta tässä on kyllä kyse zero-day exploitin kaltaisesta asiasta. Joko Intelin insinöörit ovat puusilmiä, mitä en usko, tai sitten todennäköisemmin kyseessä on ollut tietoinen tehokkuusoptimointi.
Räpylä pystyyn kuka oikeasti tekee koodissa input-validoinnin aina ja kaikkialla vaikka siitä kriittisellä polulla tulisikin lisää viipeitä koodiin?
Kyllä se intelilläkin on estetty.
Se estäminen vaan on tehty viivästetysti siten, että se rikkinäisen muistiaccessin sisältävä käsky nostaa poikkeuksen, jolloin tulosta ei koskaan tallenneta mihinkään arkkitehtuurillisesti näkyvään rekisteriin, kun se laittoman muistiaccessin tehnyt käsky eikä mikään sen jälkeen tuleva käsky ei koskaan valmistu.
Ja sitä poikkeusta ei saa laukaista heti, vaan kaikki alkuperäisessä koodissa sitä ennen olevat käskyt pitää ensin suorittaa loppuun, ja poikkeus laukeaa vasta kun ne on suoritettu, koska koodin pitää toimia täysin samalla kuin liukuhihnoittamaton, käskyjä uudelleenjärjestelemätön prosessori sen suorittaisi.
Mutta joo, onhan se mahdollista että se rikkinäisen osoitteen sisältävä latauskäsky AMDllä abortataan jo heti suoritusvaiheessa. Pidän tätä kuitenkin epätodennäköisenä, koska se tarkoittaisi sitä, että prosessorin pitäisi samalla sekä heti suoritusvaiheessa abortoida se latauskäsky(ja insertoida jotain roskaa tai joku hautakuvimarkkeri sen tulokseksi), että kuitenkin laukaista se sen aiheuttama poikkeus vasta viivästetysti myöhemmin kun on sen käskyn valmistumisen aika.
Tämä on kylläkin nimenomaan ~40-day exploit eikä zero-day exploit.
Juu koska ensireaktio oli pakottaa PTI päälle kaikille x86 arch prossuille. Myöhemmin joku laittoi julkiseksi patchin jossa ehtoa muokattiin siten että PTI pakotettiin päälle vain jos x86 suoritin ei ollut AMD:n valmistama.
Sen mitä olen asiasta lueskellut verkosta vaikuttaa että Intel on tietoisesti skipannut yhden trust boundaryn vahtimisen koska se vaatisi ylimääräistä prosessointia ja näytti siltä että boundaryn rikkominen ei ollut päätöstä tehtäessä mahdollista. Noh jos tarkistukset olisi toteutettu joka tapauksessa niin se että joku myöhemmin onkin löytänyt tavan injektoida hyökkäyskoodia rajalle ei olisi aiheuttanut loppupeleissä mitään fataalia.
SCAt mielestäni ovat aina haavoittuvuuksia, joissa käytetään hyväksi varsinaisen ilmiön sivuvaikutuksia, kuten hyvin tuossa leipurianalogiassa esitit. Tämä haavoittuvuuden hyödyntäminen ei kuitenkaan vaadi mitään muuta kuin koodia eikä siksi mielestäni kelpaa sivukanavahyökkäykseksi.
Ei, se tarkastus kyllä tehdään. Prosessori heittää aina poikkeuksen ennen kuin se laittomasti ladattu data ilmestyy arkkitehtuurillisesti näkyviin.
Mutta siihen tarkistuksen tulokseen reagoidaan liian myöhään, koska se perusteella välimuisti pollutoituu, ja SCAlla välimusitin pollutoitumisesta voidaan päätellä asioita.
Kyllä
Tässä määritelmäsi SCAsta on väärä. Kyllä ne monet aiemmatkin SCAt on ihan ohjelmakoodilla exploitattavissa, eikä tämä sen suhteen eroa niistä mitenkään. Itse asiassa jotkut aiemmat SCAt perustuvat siinä mielessä samaan mekanismiini, että niissäkin profiloidaan latauskäskyjä ja sen perusteella päätellään, mitä välimuistista löytyy. Niissä vaan hyökkäyksen toimintamekanismi on muuten ollut hyvin erilainen, niissä on vakoiltu esim. toista samalla ytimellä ajettavaa säiettä yhteisen välimusitin käytöksen perusteella.
Ja tässä exploitissa se laittomasti ladattu data ei koskaan ole käytettävissä/havaittavissa millään suoralla arkkitehtuurillisella keinolla.
Siihen pääsee käsiksi ainoastaan mittaamalla muiden latauskäskyjen suoritusaikaa ja päättelemällä sen perusteella, mihin osoitteisiin prosessorin välimuisitista viittaa. Tämä on nimenomaan SCA.
Olin väärässä tästä.
Javascriptissä voi osoittaa taulukon yli, ja prosessori voi spekulatiivisesti suorittaa sitä latauskoodia ennen kuin se taulukon kokotarkastus laukeaa.
Tämän exploitin hyödyntäminen javascriptistä on kuitenkin todella paljon vaikeampaa kuin Cstä+assemblystä koska javascriptissä ei oikein pääse suoraan osoitteisiin käsiksi, eikä muutenkaan pysty kontrolloimaan niin tarkasti sitä koodia että osaa virittää sille sopivan ajoituksen.
En ole nyt ollenkaan vakuuttunut että kyseessä oleva vulenerability on vain side channel tyyppisellä attackilla hyödynnettävissä. Registerin eilisessä analyysissä erästä toista sca:taan tehtyä patchityyppiä sanottiin käytettävän tämänkin torjuntaan, mutta silti tät arveltiin pahemmaksi.
@hkultala olet nyt siis satavarma että tässä virheessä data ei näy suoraan?
Voi pojat, kun nyt olisi menossa centerin päivitys ja laite tilaukset sisällä 😀
Uskoisin hien nousevan pintaan sen normaalin %- päivityksen vaihtuessa ja nykyisen kokoonpanon suorituskyvyn häviävän samaan aikaan…
En satavarma, mutta melko varma. Se tiedetään käytännössä varmasti, että tämä koodi liittyy spekulatiiviseen suoritukseen.
Ja ei sillä spekulatiivisesti suoritetulla datalla oikein ole mitään "virallista" reittiä tulla arkkitehtuurillisesti näkyville, koska spekulatiivisen suorituksen pointti on, että jos sitä ei pitänytkään suorittaa, se perutaan. Ja näitä on kyllä testattu perusteellisesti, ja ties mitkä softat olisi jo buganneet pahasti jos se spekulatiivisen suorituksen seurauksena syntynyt data olisikin näkyvissä jossain (siellä aiemmin olleen datan sijasta).
Tekee tämä bugi muuten helvetin hyvää Braswell-celeronilla pyörivälle kympille :dead:
Kyseessä on valmistusvirhe, joka ei käytännössä vanhene koskaan, eikä prosessori täytä enää sille myydessä luvattuja arvoja. Periaatteessa voisi aivan hyvin vaatia hyvityksiä jostain 10v vanhoista prossuistakin.
Tuo on vähän sama, kuin autosta huollon yhteydessä poistettaisiin viides vaihde. Tuskin kovin moni sitä mukisematta nielisi.
Tekee aika hallaa kaikille näille low power prossuille, apollo lake yms, ja uusi gemini lake myös.
Täyttääpäs.
Se suorittaa jokaisen käskyn aivan kuin sen spesifikaatio sanoo, tasan siinä ajassa kuin mitä sen spesifikaatio sanoo.
Tämä ei ole bugi, tämä on feature.
Seuraava on mihinkään perustumatonta jorinaa:
Onko asiaa pakko lähestyä noin ”monimutkaisesti”?
Jospa oikeuksien tason tarkistuksen saa menemään sekaisin tuolla spekulatiivisellä kikkailulla ja tämän jälkeen datat avautuu näkyviin?
Jos prossu hidastuu valmistusvian korvaavan paikkauksen takia, niin kyllähän se silloin on viallinen tuote ollut jo myydessä.