Comments 8
@evgley , а вот вы как считаете, можете ли вы ( не лично, компания, вы ведь в блоге компании пишете) дать гарантию на то, что с софтом от вашей компании не получится ситуация как у KrowdStrike? И если да, то ответственность какая? И каков процент надежности всего этого барахла, грузящего компы и это даже не майнинг?
По юридической части вопроса ничего ответить не могу - компетенций нет.
По технической\организационной видится что CrowdStrike могла бы избежать катастрофической ситуации если бы было реализовано хотя бы одно из:
Исходный код не содержал ошибки. Понятно что весь софт с багами, однако есть практики значительно минимизирующие шанс подобных ошибок.Например, статические и динамические анализаторы, secure coding guideline, secure code review и т.п
Было проведено тщательное тестирование, обнаружившее данную ошибку ДО выкладывания на сервера обновлений
Пусть даже сбойная версия выложена на сервера обновления. Но ведь раскатку можно делать поэтапно и мониторить ситуацию, тогда это затронуло бы на порядки меньше устройств
Все 3 описанные митигации реализованы в продуктах Лаборатории Касперского.
Что ещё хочется отметить: антивирус и операционная система - продукты, полноценно протестировать совместимость которых - задача нетривиальная ввиду бесконечного количества возможных окружений/сценариев/API. Было бы интересно иметь защиту от подобных ситуаций в архитектуре решения, делающей изначально невозможной подобные ситуации.
И тут мы плавно подходим к операционным системам с микроядром. В таких ОС антивирус был бы обычным приложением, работающим в юзер-моде. При падении чего-то в антивирусе, есть хорошие шансы что микроядерная ОС сможет это пережить.
Кстати, в Kaspersky OS микроядро :)
С другой стороны:
Даже анализаторы кода не спасают от кросс-багов, когда ошибка заложена в библиотеке, используемой ПО, но собираемой другими. Как с ssh в этом году. При этом, всё окружение с собой не унесешь, уже долбанные калькуляторы по размеру больше windows xp без драйверов.
Тестирование. Больной вопрос. Если брать узкоспециализированное ПО, то можно ограничить варианты и с достаточной достоверностью сказать что ПО с допустимым уровнем ошибок.
Согласен, при обнаружении отзывать сбойную версию и готовить хотя-бы заплатку, пока разберутся в проблеме и её решат.
Ну и микроядра не панацея. Если отвалится важный сервис - совсем не важно что вопроса к пуговицам костюма нет (ядро осталось работать).
auto newVal = hwCounter.getValue();
if (newVal != val) {
Почему бы сравнение величины с предыдущим значением не делать уже после того, как она ограничена min/max?
Тут важно что hwCounter получает значение из аппаратного счётчика, он работает как работает, и там нет никаких минимальных\максимальных значений (кроме ограничений HW)
С учётом этого нюанса пока не понял как написать лучше, и главное - чего мы этим исправлением достигнем.
Я имел ввиду, что нежелательно вызывать setVolume, если громкость уже и так максимальная. Можно добавить еще одну проверку:
auto newVal = hwCounter.getValue();
auto lastVol = volume;
if (newVal != val) {
volume += (newVal - val);
volume = std::min<int>(volume, Madbit::Volume::MAX);
volume = std::max<int>(volume, Madbit::Volume::MIN);
if (lastVol != volume) {
madwiim->setVolume(volume);
lastVol = volume;
}
val = newVal;
}Не знаю, как оно внутри устроено, но если внутри madwiim->setVolume и так есть подобная проверка, то можно ничего не добавлять, конечно.
Понял что имеется ввиду. В последней версии исходника уже исправлено. Я там правда другую штуку реализовывал: выяснилось что у разных пользователей разные предпочтения по чувствительности энкодера, сделал эту часть настраиваемой (параметр encoderSpeedDiv)
Я у себя сделал иначе. У меня в машине нет CAN-multimedia и кнопки на руле максимально "тупые". Поэтому я взял пластик от более "жирной" модели, с большим числом кнопок и сделал 2 платы.
В руле стоит 4 платы с кнопками. Суммарное количество кнопок - 16. К ним, штатнно, идёт 4 провода. И все что умеет - управлять магнитолой и переключать "экраны" на приборке.
Изначально мне хотелось добавить круиз-контроль (функционал есть, но производитель сэкономил на проводке).
Позже, мне захотелось листать треки не только на родном ГУ и управлять усилителем.
Для этого одну из плат разместил в самом руле вместо родной платы с кнопками, подвёл к ней все остальные платы, пустил "наружу" по родным двум из 4х проводов can, а по двум другим - питание. На второй плате терминировал родную проводку (управление гу и приборкой) + добавил 3 провода от круиза и 2 от can-drive (для чтения некоторых параметров). Также на этой плате расположился радиомодуль для управления сторонними системами. Всё спрятано под штатным пластиком и нигде не торчит (это была главная задача проекта).
По рассыпухе: десяток tlp172a, 2xstm32, esp32 для wifi+bluetooth (также используется для обновления прошивок на stm32), 3хcan-трансивера, разъёмы m/f с алика чтобы воткнуть в штатную проводку и ничего не резать...
Себестоимость партии из 5 комплектов в 20м году была 6к с платами, доставкой и автоматизированной сборкой у китайцев... Но один установочный комплект дешевле 5-6к не получалось, т.к. оригинальный жгут проводов руля все равно должен был бы пойти по нож. А он, на том же, алике 2-3к стоит.
Короче, мою, даже упрощённую систему (в виде full-kit), никто не готов был купить за 4-5к, зато покупали у другого обиталя форума плату с 4 кнопками за 8к)
Да здравствует кастомный автозвук, или Мой DIY Bluetooth-пульт на основе ESP32