The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Обнаружена еще одна уязвимость в 32-битной версии библиотеки..., opennews (?), 13-Июл-14, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


2. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."  –2 +/
Сообщение от A.Stahl (ok), 13-Июл-14, 10:16 
Как хорошо, что я не участвую в разработке каких-либо очень распространённых библиотек.
Я бы не захотел и всячески сопротивлялся таким костылям, как проверка адреса, по которому система выделила память. Что может быть унылей, чем пихать платформозависимые проверки в платформонезависимый по своей сути код.
Ответить | Правка | Наверх | Cообщить модератору

5. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."  +1 +/
Сообщение от Аноним (-), 13-Июл-14, 12:16 
Как хорошо, что ты не участвуешь в разработке каких-либо очень распространённых библиотек. Потому что ты некомпетентен и не умеешь читать код.
Ответить | Правка | Наверх | Cообщить модератору

12. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."  +/
Сообщение от Orduemail (ok), 13-Июл-14, 19:14 
Я полагаю, что проблема не в системе, которая где-то не там выделила память, а в тех аргументах, которые библиотека засунула в mmap. malloc из libc вряд ли на такое способен.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

13. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."  –1 +/
Сообщение от A.Stahl (ok), 13-Июл-14, 20:06 
Ты меня не понял. Мне претит не проверка указателя на факт выделения системой памяти, а проверка указателя на пересечение с каким-то диапазоном адресов просто так, поскольку где-то кто-то как-то на некоторых процессорах может укусить себя за яйцо. Ты готов в своей программе отслеживать, чтобы результат целочисленного деления не делился нацело на 11, а если таки делится, то повторять деление. И всё это лишь потому, что на серии HJ4 процессоров TYNJUX-2 это может привести к чему-то там?
Ответить | Правка | Наверх | Cообщить модератору

14. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."  +3 +/
Сообщение от Аноним (-), 13-Июл-14, 20:39 
Предлагаю сделку. Ты покажешь место в патче, вводящем такую проверку, либо выложишь видео на YouTube, где кусаешь себя за яйцо. Идёт?
Ответить | Правка | Наверх | Cообщить модератору

15. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."  +/
Сообщение от Orduemail (ok), 13-Июл-14, 22:37 
> Ты меня не понял. Мне претит не проверка указателя на факт выделения
> системой памяти, а проверка указателя на пересечение с каким-то диапазоном адресов
> просто так, поскольку где-то кто-то как-то на некоторых процессорах может укусить
> себя за яйцо.

Ну, если я тебя понял, самое неприятное в этом то, что проблемы совершенно непредсказуемы заранее, потому что невозможно знать особенности функционирования всех платформ. Но одну-две платформы я могу ведь знать во всех их особенностях на всех уровнях, начиная с таких нюансов, как количество регистров процессора и назначение каждого из них, системы команд, продолжая моделью распределения памяти, которую использует ядро/libc, и заканчивая всякими особенностями функционирования основных библиотек и используемого компилятора. А значит описанные проблемы на известных мне платформах -- не проблемы вовсе. Что же при этом творится на других платформах -- это пускай отслеживают те, кто занимается поддержкой тех платформ.

> Ты готов в своей программе отслеживать, чтобы результат
> целочисленного деления не делился нацело на 11, а если таки делится,
> то повторять деление. И всё это лишь потому, что на серии
> HJ4 процессоров TYNJUX-2 это может привести к чему-то там?

Я занимался подобным. Не потому что на каких-то там процессорах, что-то идёт не так, а потому что имела место быть довольно заморочная математика в целых числах, требовался чёткий контроль за округлением, в некоторых ситуациях были уместны assert(reminder==0), в некоторых ситациях случаи reminder!=0 приходилось обрабатывать особо. И не скажу, что это так уж сложно -- да, пришлось освежить в памяти курс теории чисел, прослушанный в ВУЗе, но это ведь не проблема.

В общем, подводя итог сказанному, не могу сказать что необходимость каждый вызов оператора / дополнять вызовом оператора % (или использовать div_t и div), была бы такой уж ужасной необходимостью, которая может оттолкнуть меня от написания кода. В некотором смысле это даже полезно, потому что заставляет держать в голове более точную модель работы кода.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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