информационная безопасность
без паники и всерьез
 подробно о проекте
Rambler's Top100Где водятся OGRыПортрет посетителя
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Google закрывает безлимитные Photos 
 Имя компании как средство XSS-атаки 
 Утекший код XP и Windows Server... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / RSN / архив / 2011 / март
2011
главная
январь
февраль
март
апрель
май
июнь
июль
август
сентябрь
октябрь
ноябрь
декабрь





Религиозный спор вокруг memcpy и glibc
dl // 31.03.11 14:51
Любопытная и поучительная история разворачивается вокруг одного обновления glibc, добравшись в последние дни и до рунетовских площадок.
[Не забывайте при копировании материала указывать полный адрес источника: //bugtraq.ru/rsn/archive/2011/03/11.html]

Предыстория восходит к далеким K&R временам, когда в стандартной библиотеке появились функции memcpy и memmove, отличающиеся поведением при обработке перекрывающихся регионов. В зависимости от расположения областей перекрытия можно обеспечить корректную работу, запустив копирование от начала либо от конца. Согласно стандарту, memmove такие проверки делает, memcpy - нет (во имя борьбы за производительность), и ее поведение в таких ситуациях не определено, хотя исторически сложилось так, что все реализации memcpy используют копирование "от начала".

Собственно же история началась в конце прошлого года, когда очередное обновление Fedora сломало 64-битный Adobe Flash. Через некоторое время выяснилось, что причина поломки - выполненная с подачи Intel'овских инженеров оптимизация memcpy в glibc, которая теперь иногда стала выполняться "от конца", обеспечивая на некоторых процессорах выигрыш в скорости в полтора-два раза.

Ну а дальше начался цирк с конями диспут между двумя основными точками зрения на проблему.

Радикальная точка зрения, которой придерживаются авторы glibc, если коротко - "адобы каазлы, а того, кто настолько глуп, что доверился исторически сложившемуся поведению, а не описанному в стандарте, нельзя подпускать к клавиатуре".

Согласно более компромиссной позиции, представленной Линусом Торвальдсом, все-таки нехорошо оставлять крайним пользователя, которому по барабану, что там внутри, но который точно знает, что после обновления системы у него ломается Flash. Хотите бороться за производительность - воткните всю оптимизацию внутрь memmove, а memcpy просто превратите в ее алиас - все равно там теперь полно проверок, которых раньше не было в исходной memcpy, и ради отсутствия которых ее поведение и оказалось неопределенным. Т.е. идея в том, что вполне можно добиться того же роста производительности, не ломая совместимость. Хотя и это не совсем так - за 40 с лишним лет существования С наверняка нашлись программисты, использующие привычное поведение memcpy наизнанку - не для копирования, а для размножения шаблона по буферу. Но их уже совсем не жалко.

Конечно, закладываться на привычное, хоть и формально неопределенное поведение - очень, очень плохо, и в том идеальном мире, в котором, видимо, живут разработчики glibc, такое поведение нужно карать высшей мерой программистско-социальной защиты. Но мы живем в реальном мире, где уже стали хрестоматийными случаи, в которых Microsoft иногда приходится в новых версиях ОС воспроизводить недокументированное поведение и ошибки, используемые в популярном софте.

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

P.S. Кстати, есть еще какие-то вопросы по поводу того, почему Линукс никогда не завоюет десктопы?

Источник: Red Hat Bugzilla, via avva lj      
теги: linux  |  предложить новость  |  обсудить  |  все отзывы (6) [7370]
назад «  » вперед

аналогичные материалы
25 лет первому сообщению о Linux // 25.08.16 20:57
MS SQL Server выйдет на Linux // 08.03.16 12:43
Серьезная уязвимость в glibc // 17.02.16 13:56
Забавная и неприятная уязвимость в Grub2 // 17.12.15 01:10
Мюнхен подумывает вернуться на Windows // 19.08.14 10:58
Двухлетняя уязвимость в ядре Linux // 15.05.13 00:37
Обвал атак на Linux // 19.02.13 19:48
 
последние новости
Google закрывает безлимитные Photos // 11.11.20 22:12
Имя компании как средство XSS-атаки // 30.10.20 17:01
Утекший код XP и Windows Server удалось собрать // 01.10.20 01:40
Дела виртуальные // 30.09.20 22:36
Простое пробивание рабочего/провайдерского NAT с помощью Tailscale // 20.08.20 03:02
400 уязвимостей в процессорах Snapdragon // 08.08.20 08:08
Яндекс неуклюже оправдался за установку Теледиска // 29.07.20 17:09

Комментарии:

Являясь пользователем, системным и прикладным программистом,... 31.03.11 23:18  
Автор: redbrick Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Являясь пользователем, системным и прикладным программистом, сочувствую системщикам. Очень печально, когда твои попытки сделать мир лучше встречаются в штыки. Предлагаю считать крайними прикладных программистов, но вернуть код всё же придётся, либо мириться с тем, что пользователи уходят на другой дистр.

..bw
На какой такой "другой дистр", системный и прикладной... 20.09.11 09:19  
Автор: some body Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Являясь пользователем, системным и прикладным
> программистом, сочувствую системщикам. Очень печально,
> когда твои попытки сделать мир лучше встречаются в штыки.
> Предлагаю считать крайними прикладных программистов, но
> вернуть код всё же придётся, либо мириться с тем, что
> пользователи уходят на другой дистр.
>
> ..bw

На какой такой "другой дистр", системный и прикладной программист? :-) Библиотека Си (glibc) - отдельный проект. Важный и которым пользуются все "дистры". Направление копирования функцией memcpy не определено, я полагаю, вполне правильно и обоснованно. И нечего ссылаться на недовольных пользователей. Которым халтурщики подсовывают свою дурацкую халтуру, в частности, в виде разного дурацкого флэша... Причём, насколько я знаю, Adobe распространяет свою реализацию вовсе без исходного кода. Вообще, возникают серьёзные сомнения насколько они вправе использовать glibc в своих закрытых реализациях флэша. Я лично не использую flash (отсюда следует, что ряд сайтов, чья работа основана на flash, "неработоспособны" на моём компьётере). Flash вообще из ряда вредоносного ПО и я рекомендую всем пользователям, особенно пользующимся Линукс, и вовсе его не использовать. Во всяком случае в процессе обычного просмотра веб, когда нет, что называется, "особых причин".
Что касается библиотеки, то вообще подобные казусы называются двоичной несовместимостью (в данном случае между разными версиями glibc). На самом деле, существует множество несовместимых реализаций Си библиотеки. И даже "конечный" (или конченный?) :-) пользователь должен знать о несовместимости и её последствиях. Однако в данном случае и этого фактически нет, поскольку, как правильно отмечено, спорный аспект поведения функции не определён и специально отмечен как неопределённый. Несколько удивляет даже то, что изменение поведения этой функции может сказаться на уже готовых программах, потому что memcpy в общем-то должна бы встраиваться прямо на место вызова и не вызываться из собственно библиотеки. Хотя, конечно, и встраивания может тоже не быть :-) Особенно, если программу создавали разного рода халтурщики, отличающиеся криворукостью. Рекламирующие себя, в качестве очередных "спасителей мира"... :-)
Складывается ощущение, что это один человек — «сам себя спросил, сам себе ответил». Всё так печально, аж жуть :-/ 20.09.11 19:35  
Автор: kstati <Евгений Борисов> Статус: Elderman
<"чистая" ссылка>
ну-ну. "попытки сделать мир лучше встречаются в штыки". Это из оперы: "Хочешь мир без войны? убей всех." 01.04.11 18:05  
Автор: kstati <Евгений Борисов> Статус: Elderman
<"чистая" ссылка>
Задет был не только адобский плагин, видел и другие жалобы... 31.03.11 20:48  
Автор: kstati <Евгений Борисов> Статус: Elderman
Отредактировано 31.03.11 20:50  Количество правок: 2
<"чистая" ссылка>
Задет был не только адобский плагин, видел и другие жалобы. На мой взгляд разработчики glibc повели себя отвратительно.
Да, в glibc не стандартизировано направление работы memcpy - не описано в документации, это факт, но менять сложившуюся более чем за два десятилетия норму без оповещения публики - дерзко.
Опричники, блин, учащие правильно читать документацию.
Да, это просто самый яркий пример по понятным причинам. 31.03.11 21:00  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
<добавить комментарий>


анонимность клоуны конференции спам уязвимости .net acrobat activex adobe android apple beta bgp bitcoin blaster borland botnet chrome cisco crypto ctf ddos dmca dnet dns dos dropbox eclipse ecurrency eeye elcomsoft excel facebook firefox flash freebsd gnome google gpl hp https ibm icq ie intel ios iphone java javascript l0pht leak linux livejournal mac mcafee meltdown microsoft mozilla mysql netware nginx novell ny open source opera oracle os/2 outlook password patch php powerpoint pwn2own quicktime rc5 redhat retro rip router rsa safari sco secunia server service pack shopping skype smb solaris sony spyware sql injection ssl stuff sun symantec torrents unix virus vista vmware vpn wikipedia windows word xp xss yahoo yandex youtube



Rambler's Top100
Рейтинг@Mail.ru



  Copyright © 2001-2020 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach