Здравствуйте, Sinclair, Вы писали:
S>>Действительно, ведь давно же можно драйвера для Windows писать на безопасном C# или каком-нибудь Spec#, но нет, сишники такие сишники. Или... Как это нельзя? S>Не, это не про драйвера на C#, а про "зачем нам Rust?"
Да нет. Это как раз про .NET-евангелистов, вроде вас, которые много лет вещали какой C++ плохой, а C# хороший и как скоро .NET захватит мир.
Уже не одно десятилетие прошло, а как-то всемирного .NET щастя с большой буквы Ща не случилось. Ни с C#, ни с прастихоспади, Nemerle.
Но ведь можно сделать вид, что ни разу не обгадились и продолжать подкалывать сишников и крестовиков, мол, так и не научились на C++ писать без разыменования указателей. Смело, да.
Можно даже на Rust кивать, мол, вот сейчас-то. Ну да ничего, мы подождем пока того же Rust-а в Windows-ядре будет хотя бы наполовину от Си и C++. До пенсии еще лет 10 есть.
Здравствуйте, Sinclair, Вы писали:
КБ>>А чего говорить то. Программисты на сишечке в очередной раз оказались программистами на сишечке. S>Ага. Очередное продакшн-опровержение мифа о том, что "Мы и в С++ умеем обходиться без Null pointer dereference".
Здравствуйте, Константин Б., Вы писали:
КБ>Если что в данной ветке возмущаются тем что админы пострадавших организаций раскатали обновление не проверив.
Вроде бы эти обновления применялись автоматически, даже если политики явно запрещали обнволения, т.к. это "только данные".
Здравствуйте, B0FEE664, Вы писали:
BFE>Откуда известно, что это был С++?
Возможно, это был plain C, но в нём-то как раз вовсе нет способов избежать NRE.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
BFE>>Откуда известно, что это был С++? S>Возможно, это был plain C, но в нём-то как раз вовсе нет способов избежать NRE.
Здравствуйте, vdimas, Вы писали: V>Т.е. это "ваши" подосрали, а не "наши".
Вы сейчас к кому примазываетесь-то? Кого вы "нашими" называете? V>Суть проблемы — подписанный и абсолютно исправный драйвер оказался способен исполнять внешний подгружаемый p-код. V>Всё-таки, доигрались в "легко обновляемые байт-коды", дебилы, Б.
В который раз поражаюсь вашей способности читать всё наоборот.
1. "Способность исполнять внешний подгружаемый p-код" является не багом, а фичей драйвера
2. Выполнение NRE при исполнении внешнего подгружаемого кода является не фичей, а багом драйвера.
"абсолютно исправный" драйвер не вызвал бы NRE при исполнении произвольного байт-кода.
Склонен согласиться с автором https://medium.com/@vkoukis/the-root-cause-for-the-recent-crowdstrike-mess-is-not-a-content-update-it-is-a-bug-in-csagent-sys-c3904570f78a
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
КБ>Если что в данной ветке возмущаются тем что админы пострадавших организаций раскатали обновление не проверив.
Я не уверен, что у них вообще был такой выбор. Зачастую это либо политика доверия вендору, либо вовсе отсутствие такой фичи. Тут же еще тонкий вопрос, баг проявляется только при рестарте. Могли и попросту не заметить.
C>А откуда инфа? Потому что у всех объяснения разные, кто в лес кто по дрова.
Это на официальном сайте КраудСтрайк описано.
От того, что они назвали код "конфигурацией", суть не поменялась. Как я уже тыщу раз объяснял, нет никакой конфигурации, — все это лишь код, написанный без тестов и на другом языке.
Здравствуйте, SkyDance, Вы писали:
SD>Это на официальном сайте КраудСтрайк описано. SD>От того, что они назвали код "конфигурацией", суть не поменялась. Как я уже тыщу раз объяснял, нет никакой конфигурации, — все это лишь код, написанный без тестов и на другом языке.
Про файл конфигурации да. А там разве есть что-то про байт-код?
C>Ну да, в конфиге могут быть байт-код или скрипты. Просто мне интересно откуда данные, что у клоунстрайка было сделано именно так?
Так написано в официальном блоге. Если кратко, это код для виртуальной машины csagent.sys. Можно называть его как угодно — сигнатурой, байт-кодом, конфигурацией, но сути это не меняет, — в зависимости от того, что написано в этом самом C-00000291-xxx.sys, будут выполняться разный код.
Здравствуйте, SkyDance, Вы писали:
SD>Думаю, что на Расте было бы не то же самое. Проблема выразилась бы как-то иначе, например, в зависании машины без синего экрана.
Проблема и выразилась в зависании машины при прогоне высокоуровневого сценария.
Низкий уровень там был не при чём.
Здравствуйте, Sinclair, Вы писали:
V>>Т.е. это "ваши" подосрали, а не "наши". S>Вы сейчас к кому примазываетесь-то? Кого вы "нашими" называете?
Это на кого ты пытаешься свалить ошибки "вашей" безответственной братии.
V>>Суть проблемы — подписанный и абсолютно исправный драйвер оказался способен исполнять внешний подгружаемый p-код. V>>Всё-таки, доигрались в "легко обновляемые байт-коды", дебилы, Б. S>В который раз поражаюсь вашей способности читать всё наоборот. S>1. "Способность исполнять внешний подгружаемый p-код" является не багом, а фичей драйвера
Т.е. багом архитектуры, опять бгг.
Мне уже примерно понятны зигзаги карьеры их технического руководства.
Т.е., вот тебе пошло уже вредительство от игрушечных технологий "генного" плана — это когда разрабы с геномом фриков-лалашек растут по карьёрной лестнице и тянут свои шаловливые ручки к рычагам принятия решений.
Время-то идёт, проблема "низкой планки входа" уже пустила корни и даёт свои плоды во втором поколении, в поколении технического руководства.
И твои попытки бегать от первопричин проблемы лишь её усугубляют.
Вы все как под копирку, хосподя, такие же раздражающие своей близорукостью и безответственностью.
В реальной работе я бы тебе гвоздя ржавого не доверил, я ж помню твои эксперименты по генерации кода на C# — степень самокритичности примерно нулевая, зато степень очковтирательства и изворотливости — примерно максимально возможная. И это когда уже совсем разжевали и в рот положили сценарии, где код даёт ошибку. Только почему-то посторонний vdimas видит эти косяки сходу, за единицы/десятки секунд, а потративший кучу времени на тему автор с трудом "догоняет" даже спустя несколько раундов объяснений, бгг...
А сдаётся мне, что автор тупо врёт — да не может же он быть НАСТОЛЬКО тупым.
Автор просто врёт себе, врёт окружающим.
Т.е. из-за какого-то странного дефекта психики предпочитает уходить в выдуманный мир по каждой мелочи, если хотя бы немного начинает чувствовать себя дискомфортно, бгг...
S>2. Выполнение NRE при исполнении внешнего подгружаемого кода является не фичей, а багом драйвера.
Чего? ))
Похоже, ты совсем не вдупляешь происходящее — драйвер честно перехватил ошибку и честно отрапортовал наверх с обязательной диагностикой и кодами ситуации, иначе никакого BSOD не было бы и близко, было бы тупое подвисание или что-то в этом роде.
BSOD — это, как раз, штатный сценарий реагирования на ошибки ядерного уровня.
Похоже, в более высокостоящей архитектуре всей этой приблуды не прописали сценарий — как реагировать на проваливающиеся аж на уровень VM тупые NRE байт-кода, бгг...
Такие вещи разрабатываются на архитектурном уровне и выдаются в кач-ве ТЗ техническими лидерами проекта.
Кароч, это не баг в C++, по крайней мере, никакой ошибки в C/C++ в произошедшем нет, бо на этом уровне отработали штатные ср-ва, которые помогли сразу же локализовать проблему.
Да, я понимаю твои рассуждения: "в уютном коде, выполняющемся на уровне ядра, могут быть ошибки, и VM должен был обыграть их как-то более гладко!"
Напомню, что это код уровня ядра...
Даже если это байт-код.
И что ошибки в нейтиве на этом уровне, когда могут быть локализованы, приводят к отключению подсистемы или к BSOD, если нормальное функционирование системы далее невозможно.
А когда ошибки на этом уровне не могут быть локализованы, то машина ведёт себя произвольно — дай бог где-то диагностика заметит какой-то бред и насильно перегрузит (полно и такого кода в мониторе ядра), а так-то поведение машины может стать произвольным — "подвиснуть", "тормозить", не работать часть систем и т.д.
Вот и получается, что для более простого, более безопасного языка ты требуешь еще большей толерантности, хотя должно было быть, по-идее, ровно наоборот — ведь "сложнее ошибиться" (С) Синклер!
А на деле, пресловутый NRE ты мог получить даже просто закрыв Windows.Forms в неудачный момент — это ж привычные постоянно исправляемые сомны багов на уровне C#.
Я ведь тщательно слежу за дотнетом еще с 2002-го и сам кучу раз репортил — да не бывает такой плотности багов в нейтивной разработке ни за что и никогда, оно бы ничего и никогда не работало с таким отвратительно-несерьёзным подходом. ))
А дотнетный Решарпер в Студии отваливается десятки раз за день до сих пор, бгг...
Хорошо хоть они догадались разбить его на модули меньшего размера, чтобы при краше модуля подгружать/инициализировать лишь его, а не весь монструозный плагин.
Но такой подход — это роспись в собственной убогости, разумеется.
За 20 лет не могли отловить баги, бгг.
Жесть, конечно...
(По моим наблюдениям, один из самых популярных классов ошибок в дотнете — это ошибки синхронизации в многопоточных приложениях, что провоцируется той лёгкостью, с которой произвольный объект может служить примитивом синхронизации и сочетанием всевозможных выделенных примитивов синхронизации со "встроенным" в каждый объёкт, включая механизмы монитора Pulse/PulseALL — иногда такую кашу приходится разгребать... Помнится, я тебе на пальцах показывал, как решаются задачи сложной синхронизации многих подсистем через наработки ТМО, но ты слишком усердно бегал, хотя второе образование получил по близкой моей специализации и эту теорию вам давали, но, видать, это "слишком сложно" для "уютного мирка", бгг...)
Ни один стресс-тест из моих разработок их наколенное поделие, Решарпер, никогда бы не пережило, даже в тех ситуациях, где, казалось бы, "всегда работает".
Да и вообще — что мешает собирать диагностику падений и оперативно исправлять баги?
Некому?
Нет достаточно грамотных спецов сугубо по технической части?
Одни прожжённые прикладники там собрались или как? ))
Когда мне в руки на "поиграть" попадает нечто, что "долгие годы исправно работает" (произносится громко, причём сразу от нескольких опытных разрабов) — у меня оно всё начинает резко падать и захлёбываться собственными соплями. ))
Как раз специализируюсь на поиске ненадёжностей в т.ч. в архитектурном плане и в выработке решений по ним.
S>"абсолютно исправный" драйвер не вызвал бы NRE при исполнении произвольного байт-кода.
Ты действительно не понимаешь, или намеренно работаешь на публику?
Это вполне "законный" NRE уровня виртуальной машинки.
Ну как "законный".
Ужас-ужас, конечно, но разработчики на управляемых языках особо не парятся.
Ты склонен бегать аки ужик на сковородке тут — по ссылке тоже исходят из того, что ошибка была "логическая".
И тоже правильно поняли происходящее — сначала нашли как проблему обойти, а только потом (и неизвестно когда) будут решать как проблему решить.
И да, этому идиотизму посвящена чуть ли не половина твоей ссылки, что говорит о твоей недалёкости, коль даёшь НАСТОЛЬКО низкопробные ссылки — ведь автор не может знать всех подробностей архитектуры решения, как и подробностей происходящего, т.е. вольно или невольно скатывается в банальную желтушность, в распускание слухов, бгг...
===========
Пока что единственное о чём можно делать выводы — пресловутый "порог вхождения уютных языков" привёл к самому масштабному мировому сбою за всю историю IT!
Прилетел бумеранг...
Вас теперь этим будут тыкать каждый раз как позволите себе впредь выделываться и надувать щёки. ))
===========
Вопрос не так прост, как кажется на первый взгляд, бо не позволяет отделять разработчиков друг от друга, ведь даже если в "уютную" область входит достаточно опытный разработчик, навроде тебя, он с некоторой ощутимой вероятностью расслабляет булки на твой же манер, среда-то "безопасная!"
"Выкинет исключение, а не молча отформатирует диск!" (С)
Ну вот среда и выкинула исключение, бгг...
Заодно помножила на ноль все ваши фантазии, коих наслушались за эти 20 лет.
ИМХО, IT надо тупо возвращаться к истокам, к накопленному ранее опыту и определённому менталитету инженера-программиста, независимо от языков и сред.
Фричество не работает, за это уже не первый раз больно прилетает бумеранг.
Здравствуйте, Sinclair, Вы писали:
BFE>>Откуда известно, что это был С++? S>Возможно, это был plain C, но в нём-то как раз вовсе нет способов избежать NRE.
NRE произошёл не в С/С++ ))
Хватит уже распускать слухи.
И да, в Си без проблем вешать обработчики исключений, как и в С++, ес-но, с использованием того же ABI setjmp/longjmp, т.е. не только через языковые ср-ва try-catch.
Здравствуйте, SkyDance, Вы писали:
SD>Я не уверен, что у них вообще был такой выбор. Зачастую это либо политика доверия вендору, либо вовсе отсутствие такой фичи. Тут же еще тонкий вопрос, баг проявляется только при рестарте. Могли и попросту не заметить.
Что странно, ведь основное тестирование обновлений выполняется на виртуалках, т.е. сценарий неоднократного перезапуска при обновлении системы именно так и тестируется.
Здравствуйте, Константин Б., Вы писали:
КБ>Если что в данной ветке возмущаются тем что админы раскатали обновление не проверив.
Это вряд ли.
Учитывая малый процент сбойных машин, на которые попало обновление, сбой мог просто не выстрелить при тестировании.
Т.е. тут вопросы больше к методике тестирования.
Лично меня напрягает то, что сам драйвер протестирован и подписан мелкомягкими, т.е., скорее всего, протестирован достаточно хорошо.
А вот подгружаемый на ядерный уровень байт-код, исполняемый драйвером, тестируется только вендором и не требует подписи, т.е. его надёжность на совести конкретного вендора.
Немного разрывчик шаблона, не? ))
И ожидаемый однажды приплызд за такие выверты.
