Vlákno názorů ke zprávičce Linuxové jádro je možné shodit pomocí série paketů, chyba je stará 10 let od dr_ak - Asi důležitá informace - rychlý workaround na postižených...

Z tohohle workaroundu nemám dobrý pocit, jsem zvědav, kolik lidí si to v panice nastaví někde v sysctl.d a pak to po updatu zapomenou vrátit zpátky. (A už vůbec si nedělám iluze, kolik si jich nastaví tcp_min_snd_mss, pokud to za ně neudělá distribuce.)

Tak zrovna u TCP SACK je naopak obecne doporucovano jej v nekterych (bezne provoznich) situacich vypinat, takze zas takove drama bych z toho nedelal :-) Obecne plati, ze ne vse defaulne nastavene v distribuci je univerzalne optimalni - a dopady tohoto kroku (pozitiva i negativa zmeny s ohledem na lokalni prostredi) by si kazdy mel zhodnotit sam dle sveho prostredi nezavisle na tom, ze zrovna vysla nejaka bezpecnostni advisory...

Kdysi dávno se opravdu doporučovalo zakazovat SACK, ale to bylo hlavně kvůli rozbitým implementacím a už je to opravdu hodně dávno. Bohužel se občas setkám s tím, že to někdo doporučuje ještě dnes, ale to už svědčí spíš o tom, jak moc dotyčný zaspal dobu.

Kvuli zmrsenym implementacim stejne tak muzou nastat problemy pri zahazovani paketu s nizkym MSS v duchu mitigacnich kroku k CVE-2019-11479 - a zde se mnohdy argumentuje modernim IoT, kde to muze byt problem. Jak uz jsem psal, aplikace workaroundu vzdy zalezi na konkretnich podminkach.
Stejne tak duvodem pro vypnuti TCP SACK v kernelu muze byt nejen zmrsena implementace, ale nekdy i vykonnova optimalizace - ono si to vezme nejaky ten procesorovy cyklus navic, zapnute to dava smysl hlavne na linkach s vysokou latenci, nebo tam kde je packet-loss.. Ostatne to, ze to je dobry sluha, ale nekdy zly pan dokazuje treba i lonsky commit do 4.18, kde to je pekne i popsane (fuel to fire) - ale zas muzeme obratem vest flame o tom, ktere distribuce maji tak "cerstvy" kernel ;-)