Во-вторых, не смог сходу найти статей про конкретно Boost.Regex от John Maddock, в которых бы демонстрировался ReDOS. Одну обзорную статью нашёл, в которой было много движков разобрано, там приводился конкретный пример, но я не смог воспроизвести атаку: ImHex отработал очень быстро.
Вот все места, где у нас используется standalone Boost.Regex
По-моему, если пользователь введёт дурной паттерн, то он имеет шанс самостоятельно закопаться, уж такова природа работы с неизвестными данными. Он с тем же успехом может не рассчитать, хватит ли у него оперативы для какой-нибудь другой тяжёлой операции, и прогореть. Если ReDOS страшнее, чем это, надо будет подумать.
В-третьих, Re2 тащит за собой Abseil (кучу либ, дополнующий стандартную либу плюсов), т.е. наступает на грабли самого Буста.
Да фиг бы с ними - с компайл-тайм регулярками... std::regex тупо небезопасен - мэтчинг по конечному автомату реализован рекурсивно, а не итеративно, поэтому на некоторых входах оно просто сегфолтит из-за stackoverflow, роняя всё приложение. Этот баг был замечен в gcc ещё в 2010х годах, но его не починили, как я понял, из-за ABI. Итеративный regex есть в boost, но... Процитирую автора ImHex:
Oh yeah, boost regex depends on:
assert
concept_check
config
container_hash
core
integer
mpl
predef
smart_ptr
static_assert
throw_exception
type_traits
Нет, бывает и больше зависимостей...
Впрочем, какие-то энтузиасты смогли переписать бустовый regex, чтобы он полагался только на стандартную либу, так что мы перешли на эту standalone версию. Вариант "не пихать туда непроверенный ввод" не годится, т.к. ImHex делает поиск в файле, который открывает пользователь.
Так, ничего не понимаю. Если релокацию планируют писать внутри мувающего оператора присваивания, то откуда компилятор должен вытащить информацию, как реализован этот мув? А ему придётся это узнать, чтобы решить - вставлять ли на выходе из скоупа деструктор локальной переменной или нет. А вдруг std::relocate вызывается только в какой-то ветке, что тогда делать компилятору?
Бедный assume[[expression]] (since C++23)... Контракты полностью его функционал покрывают (а он покрывает компайл-тайм фичи контрактов).
Вопрос - а у нас есть возможность в C++26 мувнуть куда-то локальный std::unique_ptr таким образом, чтобы компилятор понял, что вставлять вызов деструктора уже не надо? Ну или какой-нибудь другой класс, который либо владеет ресурсом, либо не владеет, скажем, std::any?
Хотелось бы что-то в духе Авито, который не раскрывает телефоны продавцов покупателям, но может их соединить через себя (именно звонок, а не чат). Т.е. раскрывать почту или нет - всё-таки дело автора канала.
Предположим даже, что обёртка MIPSOpcode , которая представляет из себя Memory::Opcode всегда будет иметь значения из того же диапазона, что и uint32_t, а переменные a и b , которые удачно объявлены как int, никогда не будут отрицательными.
Сейчас вообще не понял)
Ну, Memory::Opcode олицетворяет 4 байта, в которых закодирована команда процессору (RISC, всё такое, удобно), конечно, он будет принимать значения, как и то, что у него под капотом - uint32_t. А как объявлены переменные a и b, неважно, т.к. мы срезаем битовыми масками по степени двойки в каждом случае.
Что же касается рефакторинга... Ну, у нас есть тесты. Их мы гоняем на каждый PR, чтобы сравнить, не перестали ли мы походить на реальную PSP. Да-да-да, покрытия идеального не бывает, избыточность тестирования... Это всё ясно, но лучше варианта нет. Те же статические анализаторы могут ошибаться, как мы видим.
Что касается dummyThreadHackAddr, я его просто ещё не отрефакторил. Месяц назад я вытащил код, относящийся к системе AdhocMatching, в отдельные файлы, а потом почистил hadouken codestyle. На очереди AdhocCtl как раз, просто руки не дошли.
С Int_VecDo3 разве не ошибка в анализаторе? Смотрите, GetNumVectorElements возвращает числа из множества {0, 1, 2, 3, 4}. Если n >= 1 , то проблемы с n + n - 2 нет. Значит, беда будет в случае n == 0. Это бывает, если аргумент GetNumVectorElements, полученный в строке VectorSize sz = GetVecSize(op);, не лежит во множестве {V_Single, V_Pair, V_Triple, V_Quad} == {1, 2, 3, 4}. Хорошо, а что же такое GetVecSize?
static inline VectorSize GetVecSize(MIPSOpcode op) {
int a = (op >> 7) & 1;
int b = (op >> 14) & 2;
return (VectorSize)(a + b + 1); // Safe, there are no other possibilities
}
MIPSOpcode - просто обёртка над uint32_t. Как видим, здесь вычисляются a и b. Первое - либо 0, либо 1. Второе - либо 0, либо 2. Поэтому их сумма принадлежит множеству {0, 1, 2, 3}. Докидывая в сумму единичку, получаем {1, 2, 3, 4}, т.е. sz всегда корректно, а значит, n тоже.
Почему-то с Амиго ни разу не столкнулся, а вот агрессивную рекламу ЯБ заметил ещё много лет назад и тогда зарёкся его ставить из-за этого. Причём аж дважды чуть не установил (шло "в комплекте" с какой-то прогой).
А я запутался, кстати! Уж было хотел написать гневный комментарий, что в виртуальном окружении не должно быть файлов проекта, а потом увидел создание .venv...
Наверное, чтобы увеличить расширяемость/взламываемость (hacking) приложения. Вот кто сходу из присутствующих сможет набросать в форке CE новую фичу? Я на Паскале не прогал с начала 10 класса, наверное. Сейчас на 4 курсе вуза уже, мой мозг принял плюсы, Питон и ±шарпы. Оно и неприятно уже немного - спускаться в эти дебри нестандартного синтаксиса...
Латинский тоже по кусочкам изучают. Ну, я изучал так в своей гимназии.
Сначала первое склонение, первое спряжение... Потом второе и четвёртое спряжения, второе склонение мужского рода... Третье спряжение, средний род, прилагательные первого-второго склонения... Причастие настоящего времени, имперфект, местоимения, повелительное наклонение, простенький пассивный залог. Это был пятый класс у меня. Потом уже пошли более сложные штуки (перфект, PPP, футурум, все три вида третьего склонения, четвёртое и пятое склонение, accusativus cum infinitivo, nominativus cum infinitivo, ablativus absolutus, функции падежей, конъюнктив, плюсквамперфект, сложные предложения).
Ну да.
Я на это отвечаю.
Для каждого нового репозитория ведь `--global` не нужен...?
Научные гипотезы могут быть либо опровергнутыми, либо ещё не опровергнутыми.
Во-первых, да, было бы!
Во-вторых, не смог сходу найти статей про конкретно
Boost.Regexот John Maddock, в которых бы демонстрировался ReDOS. Одну обзорную статью нашёл, в которой было много движков разобрано, там приводился конкретный пример, но я не смог воспроизвести атаку: ImHex отработал очень быстро.По-моему, если пользователь введёт дурной паттерн, то он имеет шанс самостоятельно закопаться, уж такова природа работы с неизвестными данными. Он с тем же успехом может не рассчитать, хватит ли у него оперативы для какой-нибудь другой тяжёлой операции, и прогореть. Если ReDOS страшнее, чем это, надо будет подумать.
В-третьих, Re2 тащит за собой
Abseil(кучу либ, дополнующий стандартную либу плюсов), т.е. наступает на грабли самого Буста.Да фиг бы с ними - с компайл-тайм регулярками... std::regex тупо небезопасен - мэтчинг по конечному автомату реализован рекурсивно, а не итеративно, поэтому на некоторых входах оно просто сегфолтит из-за stackoverflow, роняя всё приложение. Этот баг был замечен в gcc ещё в 2010х годах, но его не починили, как я понял, из-за ABI. Итеративный regex есть в boost, но... Процитирую автора ImHex:
Нет, бывает и больше зависимостей...
Впрочем, какие-то энтузиасты смогли переписать бустовый regex, чтобы он полагался только на стандартную либу, так что мы перешли на эту standalone версию. Вариант "не пихать туда непроверенный ввод" не годится, т.к. ImHex делает поиск в файле, который открывает пользователь.
Так, ничего не понимаю. Если релокацию планируют писать внутри мувающего оператора присваивания, то откуда компилятор должен вытащить информацию, как реализован этот мув? А ему придётся это узнать, чтобы решить - вставлять ли на выходе из скоупа деструктор локальной переменной или нет. А вдруг std::relocate вызывается только в какой-то ветке, что тогда делать компилятору?
И что, он вызовет мув-оператор копирования / мув-конструктор? Я именно про мув говорю.
Бедный
assume[[expression]] (since C++23)... Контракты полностью его функционал покрывают (а он покрывает компайл-тайм фичи контрактов).Вопрос - а у нас есть возможность в C++26 мувнуть куда-то локальный
std::unique_ptrтаким образом, чтобы компилятор понял, что вставлять вызов деструктора уже не надо? Ну или какой-нибудь другой класс, который либо владеет ресурсом, либо не владеет, скажем,std::any?Хотелось бы что-то в духе Авито, который не раскрывает телефоны продавцов покупателям, но может их соединить через себя (именно звонок, а не чат). Т.е. раскрывать почту или нет - всё-таки дело автора канала.
Верно, можете посмотреть мой вклад: https://github.com/hrydgard/ppsspp/pulls/Nemoumbra
Сейчас вообще не понял)
Ну,
Memory::Opcodeолицетворяет 4 байта, в которых закодирована команда процессору (RISC, всё такое, удобно), конечно, он будет принимать значения, как и то, что у него под капотом -uint32_t. А как объявлены переменныеaиb, неважно, т.к. мы срезаем битовыми масками по степени двойки в каждом случае.Что же касается рефакторинга... Ну, у нас есть тесты. Их мы гоняем на каждый PR, чтобы сравнить, не перестали ли мы походить на реальную PSP. Да-да-да, покрытия идеального не бывает, избыточность тестирования... Это всё ясно, но лучше варианта нет. Те же статические анализаторы могут ошибаться, как мы видим.
Что касается
dummyThreadHackAddr, я его просто ещё не отрефакторил. Месяц назад я вытащил код, относящийся к системеAdhocMatching, в отдельные файлы, а потом почистил hadouken codestyle. На очередиAdhocCtlкак раз, просто руки не дошли.С
Int_VecDo3разве не ошибка в анализаторе? Смотрите,GetNumVectorElementsвозвращает числа из множества{0, 1, 2, 3, 4}. Еслиn >= 1, то проблемы сn + n - 2нет. Значит, беда будет в случаеn == 0.Это бывает, если аргумент
GetNumVectorElements, полученный в строкеVectorSize sz = GetVecSize(op);, не лежит во множестве{V_Single, V_Pair, V_Triple, V_Quad} == {1, 2, 3, 4}. Хорошо, а что же такоеGetVecSize?MIPSOpcode- просто обёртка надuint32_t. Как видим, здесь вычисляютсяaиb. Первое - либо 0, либо 1. Второе - либо 0, либо 2. Поэтому их сумма принадлежит множеству{0, 1, 2, 3}. Докидывая в сумму единичку, получаем{1, 2, 3, 4}, т.е.szвсегда корректно, а значит,nтоже.Почему-то с Амиго ни разу не столкнулся, а вот агрессивную рекламу ЯБ заметил ещё много лет назад и тогда зарёкся его ставить из-за этого. Причём аж дважды чуть не установил (шло "в комплекте" с какой-то прогой).
Я как-то пропустил момент, когда пользователи стали уходить с дурилок на три буквы.
А я запутался, кстати! Уж было хотел написать гневный комментарий, что в виртуальном окружении не должно быть файлов проекта, а потом увидел создание
.venv...В целом, идея хорошая. Мне очень хотелось бы посмотреть на плюсовый CE со всеми графами указателей, сканнерами, etc.
Только вот это вот: 😜😋🙊 - надо бы за борт, извините.
Наверное, чтобы увеличить расширяемость/взламываемость (hacking) приложения. Вот кто сходу из присутствующих сможет набросать в форке CE новую фичу? Я на Паскале не прогал с начала 10 класса, наверное. Сейчас на 4 курсе вуза уже, мой мозг принял плюсы, Питон и ±шарпы. Оно и неприятно уже немного - спускаться в эти дебри нестандартного синтаксиса...
Блин, рекурсивное определение... А что это за фраза такая?
А что значит "тортную"?
Латинский тоже по кусочкам изучают. Ну, я изучал так в своей гимназии.
Сначала первое склонение, первое спряжение... Потом второе и четвёртое спряжения, второе склонение мужского рода... Третье спряжение, средний род, прилагательные первого-второго склонения... Причастие настоящего времени, имперфект, местоимения, повелительное наклонение, простенький пассивный залог. Это был пятый класс у меня. Потом уже пошли более сложные штуки (перфект, PPP, футурум, все три вида третьего склонения, четвёртое и пятое склонение, accusativus cum infinitivo, nominativus cum infinitivo, ablativus absolutus, функции падежей, конъюнктив, плюсквамперфект, сложные предложения).
Вот так к концу 8 класса всё и изучил.