Ох, помню я как-то такой баг вылавливал пол-дня. Соль в том, что здесь стоит незаметный символ локализации, который в зависимости от текущей локали подставит перевод строки «Untitled». В результате из-за того, что русские строки занимают в UTF-8 кодировке по два байта на символ, гарантированно возникает переполнение буфера, причём у разработчика, естественно, «всё нормально», а у клиента с русской локалью — сегфолт. Понять, что баг зависит от локали порой очень сложно.
Хотя конкретно здесь мы максимум получим «обрубок» русского текста, причём возможно между символов.
P.S. По поводу интерфейса гимпа на хабре была неплохая статья, его можно настроить под себя.
Просто вольный переводчик тактично опустил часть оригинальной фразы, которую не посчитал важной:
RAR has become a standard format for sharing files over the Internet, specifically in the distribution of pirated media.
Дословно — «RAR стал стандартным форматом для распространения файлов в Интернете, особенно для распростанения пиртаских носителей».
Как видите, в оригинале во-первых не говорится про то, что это стандарт (стандартный формат и стандарт не одно и то же), а во-вторых уточняется, для чего конкретно применяется rar в интернете.
Не вижу нигде кнопочки Download. Проект загнулся? И написано, что он основан на TOMOYO.
Если фантазировать дальше, то что вы будете делать, если опция CONFIG_SECURITY при сборке ядра оппаньки и выключена?..
Если у вас клиенты пересобирают ядро с выключением CONFIG_SECURITY то тут уже ничего не поможет. С другой стороны если нужно решать какую-то выходящую за рамки LSM задачу, достаточно наложить патч на ядро и дело в шляпе. Модули получается имеют только преимущество в том, что их проще отлаживать и распространять под проприетарной лицензией? Тем не менее, Grsecurity идёт именно как патч, да и много чего тоже оформляют как патчи, поскольку предполагают включение в апстрим.
А вот как быть с тем, что вы не можете гарантировать того, что ядро делает это?
Гарантировать никто ничего не может. Для этого нужно доказать математически, что всё, от микрокода процессора и контроллеров жесткого диска до ядра, работает именно так как декларировано. Я могу только зная заложенную в ядро идеологию говорить, что остаточную память постороннего пользователя вы не получите. Но сразу всплывает куча «НО»: система правильно настроена, в ней нет дырок и лазеек и т.п.
1) И правильно делают. Защита вне ядра — не защита.
2) Покрытие LSM достаточно для контроля доступа субъекта к объекту, к очистке памяти это отношения не имеет. В LSM должен сидеть диспетчер доступа, его задача — форсирование политики безопасности. Диспетчер доступа вообще никаких манипуляций с ресурсами не производит и не должен этого делать ни в коем случае.
А очистка памяти в наших нормативных документах — это очень вольный перевод требований LSPP, где требованием является защита остаточной информации. То есть при повторном использовании ресурса в нём не должно быть остаточных данных и это правило выполняется ядром без особых проблем. Как конкретно TCB будет предотвращать доступ к повторно используемым ресурсам — другой вопрос. Попробуйте в Linux без прав рута и читерства с ptrace хоть как-то перекинуть данные без IPC.
Это покажет вероятность возникновения хотя бы одной коллизии (пары). По данной в вики формуле получается 99%. Оно так и есть — у автора там вообще более 1к коллизий, что сильно покрывает формулировку «хотя бы одна пара». Был бы хэш md5 — совсем другой вопрос, вероятность даже хотя бы одной пары будет невелика: ~5.9e-29.
Я бы так не был уверен. При первом же запросе ваша база ложится в кэш ОСи и при последующих запросах всё крутится в оперативной памяти, а то и в L2. Т.е. вы по сути меряете производительность не диска, а оперативной памяти. Кэширование есть всегда, просто оно прозрачное. Более того, оно может сыграть злую шутку с тем, кто гоняет синтетические бенчмарки.
можно будет просто зациклить массива через побитовое И. (с) Кнут, том третий по-моему. Хотя боюсь тут уже упирается в переключение контекста из-за системных вызовов.
Так если вы всё равно пришли к хэшу, зачем CRC? Есть более быстрые и простые реализации хэша для строк. А что касается базы данных, есть ощущение, что с индексом вы что-то просто напутали. Запускайте профилировщик запроса, пробуйте хэш-индексы и innodb, которая не блокирует всю таблицу. А ещё при условии того что это копеечная (с точки зрения памяти сервера) база, есть смысл поиграться с in-memory table.
P.S. База маленькая, так что если написать грамотную реализацию на С++ с использованием Perfect Hash (гуглить gpref) и поднять всё это как демон — будет вообще ураган.
Можно увеличить обычное изображение с альфа-каналом и потом увеличить контрастность, чтобы скрыть артефакты интерполяции, но есть два НО:
при уменьшении того же изображения будут видны эффекты «лесенки» из-за особенностей интерполяции;
при увеличении изображения появится крупная заметная «лесенка» опять же из-за особенностей интерполяции на видеокартах.
Подробнее об этих артефактах и недостатках можно посмотреть в оригинальной публикации Valve (есть в конце статьи). Описываемая техника позволяет сильно уменьшить оригинальное изображение по сравнению с оригиналом (экономия видеопамяти) и масштабировать как «вверх» так и «вниз» без значительных искажений. Контур при этом получается плавным и чётким с бесплатным антиалиасингом.
Ох, помню я как-то такой баг вылавливал пол-дня. Соль в том, что здесь стоит незаметный символ локализации, который в зависимости от текущей локали подставит перевод строки «Untitled». В результате из-за того, что русские строки занимают в UTF-8 кодировке по два байта на символ, гарантированно возникает переполнение буфера, причём у разработчика, естественно, «всё нормально», а у клиента с русской локалью — сегфолт. Понять, что баг зависит от локали порой очень сложно.
Хотя конкретно здесь мы максимум получим «обрубок» русского текста, причём возможно между символов.
P.S. По поводу интерфейса гимпа на хабре была неплохая статья, его можно настроить под себя.
Дословно — «RAR стал стандартным форматом для распространения файлов в Интернете, особенно для распростанения пиртаских носителей».
Как видите, в оригинале во-первых не говорится про то, что это стандарт (стандартный формат и стандарт не одно и то же), а во-вторых уточняется, для чего конкретно применяется rar в интернете.
Если у вас клиенты пересобирают ядро с выключением CONFIG_SECURITY то тут уже ничего не поможет. С другой стороны если нужно решать какую-то выходящую за рамки LSM задачу, достаточно наложить патч на ядро и дело в шляпе. Модули получается имеют только преимущество в том, что их проще отлаживать и распространять под проприетарной лицензией? Тем не менее, Grsecurity идёт именно как патч, да и много чего тоже оформляют как патчи, поскольку предполагают включение в апстрим.
Гарантировать никто ничего не может. Для этого нужно доказать математически, что всё, от микрокода процессора и контроллеров жесткого диска до ядра, работает именно так как декларировано. Я могу только зная заложенную в ядро идеологию говорить, что остаточную память постороннего пользователя вы не получите. Но сразу всплывает куча «НО»: система правильно настроена, в ней нет дырок и лазеек и т.п.
2) Покрытие LSM достаточно для контроля доступа субъекта к объекту, к очистке памяти это отношения не имеет. В LSM должен сидеть диспетчер доступа, его задача — форсирование политики безопасности. Диспетчер доступа вообще никаких манипуляций с ресурсами не производит и не должен этого делать ни в коем случае.
А очистка памяти в наших нормативных документах — это очень вольный перевод требований LSPP, где требованием является защита остаточной информации. То есть при повторном использовании ресурса в нём не должно быть остаточных данных и это правило выполняется ядром без особых проблем. Как конкретно TCB будет предотвращать доступ к повторно используемым ресурсам — другой вопрос. Попробуйте в Linux без прав рута и читерства с ptrace хоть как-то перекинуть данные без IPC.
2^22
4194304
можно будет просто зациклить массива через побитовое И. (с) Кнут, том третий по-моему. Хотя боюсь тут уже упирается в переключение контекста из-за системных вызовов.
P.S. База маленькая, так что если написать грамотную реализацию на С++ с использованием Perfect Hash (гуглить gpref) и поднять всё это как демон — будет вообще ураган.
Подробнее об этих артефактах и недостатках можно посмотреть в оригинальной публикации Valve (есть в конце статьи). Описываемая техника позволяет сильно уменьшить оригинальное изображение по сравнению с оригиналом (экономия видеопамяти) и масштабировать как «вверх» так и «вниз» без значительных искажений. Контур при этом получается плавным и чётким с бесплатным антиалиасингом.