The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"Команда из Университета Миннесоты раскрыла детали об отправл..."
Отправлено Ordu, 01-Май-21 20:06 
> А если гипотезы нет?

Рыть данные и искать гипотезу. Мозгами шевелить, применять свою способность к распознаванию паттернов.

То есть, начать стоит с какой-нибудь теории "кухонного" уровня, можно даже уровня "теории заговора". А потом из этой теории делать предсказания-гипотезы и проверять их данными. Если этот способ срезать угол не сработает, тогда смотреть в данные и надеятся на свои способности высматривать паттерны. Если они не сработают, то мерять по каждому багу сотню параметров, и скармливать в факторный анализ, или ещё какие-нибудь интересные статистики считать. Продолжать до тех, пока не случится прихода. Лучше делать это не в одиночку, а группой из 3-5 человек: каждый ищет вроде и сам по себе, но раз в пару недель встречаетесь и делитесь мыслями.

И да, я бы предположил, что сходу найти не удастся, и если подумать недельку то тоже не удастся. Потому что разработчики и мейнейнеры подсистем постоянно эти данные наблюдают год за годом, и всё что там можно было высмотреть простого они уже высмотрели скорее всего.

> Задача поиска уязвимостей в ядре - другая.

А я не говорил про поиск уязвимостей. В смысле тебе придётся искать баги, чтобы оценивать как их туда пропихивали. Но искать эти баги проще в инете -- найти какую-нибудь базу данных багов в ядре, или может список рассылки перерыть на предмет багфиксов, и таким образом найти баги, а потом git blame подскажет бажный коммит, а потом по коммиту можно найти тред в списке рассылке. Возможно тебе придётся классифицировать эти баги, чтобы не сравнить нечаянно "вероятность пропихнуть через ревью баг класса A методом X" с "вероятностью пропихнуть через ревью баг класса B методом Y". Тебе же хочется сравнивать методы, а значит по классу надо контролировать, в том смысле, что сравнивать надо "класс A с методом X" с "класс A с методом Y". А это значит, что надо уметь измерять класс бага. Но это всё сопутствующие задачи, не умея решать которые ты просто не сможешь провести ни одного полезного исследования методов пропихивания багов.

Я говорил про то, что все эти поисковые запросы по базе данных багов или по списку рассылки неплохо было бы автоматизировать. Пускай даже и отчасти: перебор данных -- это надолго, сокращение время затрачиваемого на анализ бага даже на 10% -- это очень полезно. Если же удастся автоматизировать вообще полностью, чтобы сказать "SELECT patch, bugfix, thread WHERE bugclass="double-free" AND contains(method, "аппеляция к гомофобии") и скрипт бы так попыхтел-попыхтел, перерыл архивы списка рассылки, и выдал бы результат -- дык это вообще будет огонь. Парочку-тройку гипотез проверить, опубликовать пару-тройку статей, и ещё одну статью про этот скрипт. И потом сидеть и собирать ссылки на себя из других работ десятками. Или даже оформить в виде платной программы, и грести деньги лопатой.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
  Введите код, изображенный на картинке: КОД
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру