Vlákno názorů k článku RETBLEED: nedořešené chyby v procesorech nás budou stát až desítky procent výkonu od RDa - By me zajimalo jaky dopad na vykon ma...

By me zajimalo jaky dopad na vykon ma mitigations=off, vuci stavu kdy by v kernelu nebyla zadna zaplata ani ve zdrojaku. Jiste.. je to nejaky if(var) sem a tam.. ale presto to cloveka rozciluje, kdyz stavi embedded ostrovni system a vady cpu jsou mu.. ta tam, kam slunce nesviti.

Naštěstí je většina těch mitigací implementována přes live patching, takže těch ifů tam za běhu moc nebude, určitě ne tam, kde by to riskovalo cache miss nebo zmatení branch prediktoru.

Zase tolik bych se s tím netrápil, není to nic nového, arch/x86/kernel/cpu/bug­s.c pamatuje 90. léta, většinou se do něj jen přidává. Mají to tam pěkně tříděno pomocí maker, takže když např. stavím kernel pro nějaký embedded ARM nebo MIPS, tak se většina těch x86 větví ani nezkompiluje a zbytek to vyhází v rámci LTO, když se poštěstí. Na ARMu jsou mitigace navíc mnohem granulárnější, v configu si můžu zapnout nebo vypnout konkrétní erratum, takže když stavím něco pro jednojádrový 400MHz Cortex A7, mám jistotu, že tam nebudu mít ani jednu zbytečnou NOP instrukci navíc :-D

Pri Industry 4.0 už nie je skutočne ostrovný žiadny systém

Muzete toto marketingove tema rozvest? Nebo je to po vykradeni 5G frekvencnich pasem lobysty z velkych firem pro prumysl 12346789.006 dalsi pokus jak prodat Industry 4.0 cool cloud security solution?

I kdyz to vemu do onlinu. Jaky vliv ma retbleed na nejake zapomenute cidlo ktere jde pres svoji gw ktera sbira dejme tomu data pres nejaky cmoud? Proc bych mel strategicky dulezity system zapojovat na primo do cmoudu? Proc ty udaje nefiltrovat a do cmoudu neposilat jen vybrane?

Pokud dojde k zasazeni cmoudu tovarna musi stale jet. Jinak ten system navrhl nezodpovedny ignorant.