90% kaikista vuodoista on korjattu lauseella, älä käytä internet exploreria. Varmaan myös tässäSiihen taitaa olla hyvä syy, vai mitä mieltä olet? Linux patchin kommentitkin piilotettu, jotta vaikeampi hyväksikäyttää.
Kerro toki jos/kun niitä alkaa löytyä. Varmasti monia kiinnostaisi tietää lisää.
Minulta menee nyt kyllä sinun pointtisi ohitse aivan tyystin.
En usko että ie:n käyttö on ongelmana datakeskusten koneissa.90% kaikista vuodoista on korjattu lauseella, älä käytä internet exploreria. Varmaan myös tässä
Nyt toki keskustellaan kotikoneista, täällä on varmaan aika vähän datakeskuksien ylläpitäjiä kysymässä neuvoa.En usko että ie:n käyttö on ongelmana datakeskusten koneissa.
Mutta joo. Eiköhän me jossain kohtaa saada jotain selitystä siihen miten homma oikein meni. Voi kyllä olla että Intelin puolelta ei moista selitystä tulla koskaan saamaan
Laajuus ja vaaditut korjaustoimenpiteet ovat ainakin historiallisen suuria. Siihen nähden voisi riskienkin olettaa olevan aika isoja.
Toki ja korjaako jo valmiina olevat paikkaukset windowsissa ja linuxissa ongelmaa, vai tuleeko tästä loputon paikkauskohde.
FireStrike tuskin tekee system caleja sen jälkeen kun on ladannut tekstuurit ynnä muut levyltä (ennen benchmark runia) ja syöttänyt ne GPU:lle.Vaikutus nähdään vasta myöhemmin, mutta voin melkein luvata ettei firestrike tuloksesta lähde 30% pois.
Onhan noita CPU-intensiivisiä pelejä vaikka kuinka..
Ongelma ei ole se cpu:lla suoritettava koodi vaan muisti/levy accessit. Esimerkkinä tietokannat. Vaikuttaa toki peleihinkin, mutta niissä harvemmin I/O on pullonkaulana.
Pelkkä pelin CPU intensiivisyys ei vielä välttämättä vaikuta. Jos peli tekee system caleja tjsp jotka menevät "user space" käskyjen sijaan "kernel spaceen"vaikutusta tulee.
Kiitoksia, tämähän selvensi. Erittäin vittumaiselta kuullostaa mut onneksi kotikäyttäjää vähemmän haittaa.
Ois kyl ihan ehdoton artikkeli tämäMielenkiinnolla odotan millaiset vaikutukset käytännön suorituskyvyssä yleisimmissä tehtävissä. Kai @Sampsa ajaa ainakin suppeat testit ennen ja jälkeen päivityksen?
Vistassahan taisi näyttisajurit siirtyä userspacen puolelle, joten luulisi, ettei peleissä tule droppia.
Ajattelin että itsekin osallistun Suomessa joukkokanteeseen jos tiedot pitävät paikkaansa.Joko jenkeissä on joukkokanteet viriämässä?
Toivottavasti saavat Kernel päivityksen fiksattua niin, ettei AMD kärsi päivityksestä.
Johan amd julkaisi sen hauskan oneliner patchin.
Njoo tuossa varmaankin kyse on siitä että on paljon helpompi(==nopeampi) lyödä kategorisesti liinat kiinni ja aukoa solmuja paremmalla ajalla alustakohtaisesti. Sanamuoto on myös että vanhemmat prossut kärsivät enemmän, ei että uudemmat kärsivät vähemmän. PCID pitää emuloida vanhemmilla raudoilla, jolloin kerroksien väliin tulee entistä enempi phläskiä.
Jeh ainakin E5 v2 Xeonista on mystisesti kyseinen ominaisuus kadonnut.
Intel's CEO Just Sold a Lot of StockAMD lappu vajaassa 10% nousussa ennen pörssin aukeamista
JS ei ainakaan selaimessa mielestäni pääse suorittamaan sellaisia toimintoja joilla tätä voisi exploitata kun aika rajattu mitä siellä kuitenkin loppujen lopuksi voidaan suorittaa. Jossain node.js tms sitten voi olla eri asia, mutta se meneekin sitten server-siden puolelle.
Mielenkiinnolla odotan millaiset vaikutukset käytännön suorituskyvyssä yleisimmissä tehtävissä. Kai @Sampsa ajaa ainakin suppeat testit ennen ja jälkeen päivityksen?
Eiköhän me tätä aktiivisesti tulla seuraamaan, uutisoimaan ja testaamaanKiitoksia, tämähän selvensi. Erittäin vittumaiselta kuullostaa mut onneksi kotikäyttäjää vähemmän haittaa.
Ois kyl ihan ehdoton artikkeli tämä
Insider buildeissa tosiaan ollut fixi jo sisällä jonkunaikaa. Itse ajelin pari peli benchmarkkia FCU:lla ja uusimmalla Insider buildilla, ja eroja ei juurikaan näkynyt. Alla arvot joita sain. Koneena i5-4670K (OC 4.2 GHz), 16GB DDR3 1600 MHz (OC 1866 MHz) ja Asus Geforce GTX 980. Testi ei välttämättä ole ihan 100% tarkka, koska FCU testit on ajettu pitkään käytetyllä asennuksella ja tuo Insider taas oli täysin puhdas asennus. Suljin kyllä FCU:n puolelta kaikki ylimääräiset ohjelmat.
Ketjun lukemallahan tuo selviää
Muuttuuhan AMD:n prossu selvästi paremmaksi ostokseksi tämän myötä.
Todellakin muuttuu. Riippuu tietysti täysin miten tuo nyt lopulta tulee vaikuttamaan suorituskykyyn.
Ongelmaa ei ole AMD:n prossuilla, mutta ainakin ensimmäinen versio Linux-pätsistä jostain syystä kohtelee AMD:n prosessoreita kuin niissä olisi sama ongelma. Eiköhän loppujen lopuksi päästä tilanteeseen että ei koske millään tasolla AMD:n prossuja.
Piti paikkaansa ehkä joskus IE6:n aikaan vielä90% kaikista vuodoista on korjattu lauseella, älä käytä internet exploreria. Varmaan myös tässä
On selaimen sandboxista karkailevia javascript-exploitteja ollut ennenkin. Rowhammer.js tulee ensimmäisenä mieleen. Toinen julkaistu metodi on ASRL-muistiavaruuteen hyökkääminen välimuistin kautta: media.ccc.de - ASLR on the line
Kannattaa laittaa lähde mukaan niin voidaan vetää analyysi noista sun lukemista testeistä.
Väittivät, että AMD:n patch on hyväksytty RC7 versioon kernelistä.
Tosiaan. Tulikohan lainaus oikein, en osaa vielä käyttää. Yritän tuossa katsoa uudestaan mistä noista luin, mutta tuota Registerin artikkelia ja siinä lainattuja Postgresql:n postauksia ja noita muita linkkejä luin ja kävin sitten katsomassa sql alan foorumeita. Siinähän itseasiassa onkin he lainanneet isolla tuossa twitter postauksessaan tuota 17-23% uhkakuvaa ja postauksessa olin lukevinani että 6000 sarjan skylakella oli ajettu. Itselle ei kuulosta kovin kivalta. En usko tosin, että oikean elämän skenaariossa iskee samalla tavalla, mutta kyllä näillä on kerrannaisvaikutuksia käyttäjiin ja varmasti myös osassa normaaleja operaatioita ja pelejä. Odotan kyllä innolla jos te pääsette jossain vaiheessa testailemaan ja selvittämään asiaa paremmin, ja toivon että ei olisi mitään näin vakavaa.Kannattaa laittaa lähde mukaan niin voidaan vetää analyysi noista sun lukemista testeistä.
Ongelma tässä patchissä vaan on se, että siinä on täysin unohdettu VIAn , Transmetan yms. suorittimet. Tuon ehdon pitäisi mennä siten, että jos valmistaja intel ja prosessorin mallisarja on tiettyä suurempi, sitten enabloidaan.
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.
AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.
Disable page table isolation by default on AMD processors by not setting
the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
is set.
Signed-off-by: Tom Lendacky <thomas.lendacky@xxxxxxx>
---
arch/x86/kernel/cpu/common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index c47de4e..7d9e3b0 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -923,8 +923,8 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c)
setup_force_cpu_cap(X86_FEATURE_ALWAYS);
- /* Assume for now that ALL x86 CPUs are insecure */
- setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
+ if (c->x86_vendor != X86_VENDOR_AMD)
+ setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
fpu__init_system(c);
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.
