В гипервизоре Xen найдена критическая уязвимость (http://permalink.gmane.org/gmane.comp.security.oss.general/7851), позволяющая пользователю гостевой системы организовать выполнение кода на стороне управляющей хост-системы. Проблеме подвержены 64-разрядные хост-системы на базе процессоров Intel. Эксплуатация уязвимости возможна только из паравиртуализированных гостевых систем, базирующихся на 64-разрядном ядре. После успешной эксплуатации, привилегированный пользователь гостевой системы, а в некоторых конфигурациях и непривилегированный пользователь гостевой ОС, может получить контроль над хост-системой. Проблема связана с возможностью, в процессе возврата из системного вызова (SYSRET), создания условий для генерации исключения в неподходящем состоянии процессора.
Системы с процессорами AMD вышеотмеченной уязвимости не подвержены, тем не менее, системы с некоторыми старыми моделями 64-разрядных CPU AMD Athlon 64 и AMD Opteron, в которых не устранена 121 ошибка (http://support.amd.com/us/Processor_TechDocs/25759.pdf) в микрокоде, могут быть эксплуатированы (http://permalink.gmane.org/gmane.comp.security.oss.general/7853) для инициирования отказа в обслуживании (блокирование работы хост-системы). Кроме того, в Xen устранена ещё одна уязвимость (http://permalink.gmane.org/gmane.comp.security.oss.general/7852), дающая возможность пользователю 32- или 64-разрядной паравиртуализированной гостевой системы, инициировать крах данного гостевого окружения.
Исправления для всех трёх упомянутых уязвимостей пока доступны в виде патчей. Проследить за выходом обновлений популярных дистрибутивов можно на данных страницах: Ubuntu (https://lists.ubuntu.com/archives/ubuntu-security-announce/2.../), Mandriva (http://www.mandriva.com/en/security/advisories?dis=2011), Gentoo (http://www.gentoo.org/security/), Slackware (http://www.slackware.com/security/list.php?l=slackware-secur...), openSUSE (http://lists.opensuse.org/opensuse-security-announce/2012-04/), CentOS (http://lists.centos.org/pipermail/centos-announce/2012-June/...), Scientific Linux (http://listserv.fnal.gov/scripts/wa.exe?A1=ind1204&L=scienti...), Fedora (https://admin.fedoraproject.org/updates/F17/security), RHEL (http://rhn.redhat.com/errata/rhel-server-errata.html) и Debian (http://www.debian.org/security/).
Во всех поддерживаемых версиях FreeBSD устранена (http://lists.freebsd.org/pipermail/freebsd-announce/2012-Jun...) идентичная по своей сути уязвимость, позволяющая локальному пользователю выполнить свой код с привилегиями ядра системы. Проблема проявляется только в сборке FreeBSD/amd64 на 64-разрядных процессорах Intel. FreeBSD/amd64 на системах с процессорами AMD, 32-разрядная сборка FreeBSD/i386, а также сборки FreeBSD для других процессорных архитектур уязвимости не подвержены.
Одновременно выпущено (http://lists.freebsd.org/pipermail/freebsd-announce/2012-Jun...) уведомление об исправлении уязвимости во входящем (http://www.opennet.me/opennews/art.shtml?num=34008) в базовую поставку FreeBSD DNS-сервере Bind. Проблема проявляется при обработке полей rdata нулевой длины и выражается в крахе процесса или утечке областей памяти сервера. Кроме того, сообщается (http://lists.freebsd.org/pipermail/freebsd-announce/2012-Jun...) об устранении серьёзной ошибки в IPv6-стеке FreeBSD, которая может привести к краху ядра при большой сетевой нагрузке. Стек IPv4 данной проблеме не подвержен.URL: http://permalink.gmane.org/gmane.comp.security.oss.general/7853
Новость: http://www.opennet.me/opennews/art.shtml?num=34082
жаль нет эксплоита готового, поэкспериментировал бы на Amazon AWS
> жаль нет эксплоита готового, поэкспериментировал бы на Amazon AWSСплойт может скоро появиться, а амазон вряд ли оперативно дыру прикроет.
> которая может привести к краху ядра при большой сетевой нагрузке.Greetings going to Netflix </sarcasm>.
Дружище, как бы не я не относился к бсд, но "сарказьм" надо проявлять, только поняв, для начала, о чем новость. А то выходит петросянство.
Судя по вашим сомнениям, вы еще не поняли.
Мы поняли что у тебя есть шелл на Netfilx box'ах ... товариЩь пертосян :-)
всётки опенбсдшная параноййя на стабильность + привязанность к амд сказалась , сам сижу на 32 быта и болше 4х гигов проге не даю , аппаратно , при наличии 16 оперативы , но ось их видит тока через постраничное обращение
Я правильно читаю новость? В интеловских процессорах обнаружена бага которую решили считать фичей?
> В гипервизоре Xen найдена критическая уязвимость ...
> Проблема связана с возможностью создания условий для генерации исключения в неподходящем состоянии процессора в процессе возврата из системного вызова (SYSRET)Ошибка в Xen.
А почитать внимательно? http://www.securityfocus.com/archive/1/523076/30/0/threaded
II. Problem Description
FreeBSD/amd64 runs on CPUs from different vendors. Due to varying
behaviour of CPUs in 64 bit mode a sanity check of the kernel may be
insufficient when returning from a system call.Описание проблемы: "a sanity check OF THE KERNEL may be insufficient"
Можете дополнительно посмотреть на CVS, где английским по белому указано что ошибка в модуле trap.c, т.е. в модуле обработчика исключений.
Мне каждого здесь в его какашки носом тыкать??
> II. Problem Description
> FreeBSD/amd64 runs on CPUs from different vendors. Due to varying
> behaviour of CPUs in 64 bit mode a sanity check of
> the kernel may be
> insufficient when returning from a system call.
> Описание проблемы: "a sanity check OF THE KERNEL may be insufficient"
> Можете дополнительно посмотреть на CVS, где английским по белому указано что ошибка
> в модуле trap.c, т.е. в модуле обработчика исключений.Да, именно об этом был мой вопрос. И в Xen, и в FreeBSD фиксили неспецифическое поведение sysret на процессорах Intel, которая не проверяла адрес возврата хотя по спекам вроде как должна.
> Мне каждого здесь в его какашки носом тыкать??
А не могли бы вы разговаривать повежливее а не на уровне пятого класса школы?
> неспецифическое поведение sysret на процессорах Intel, которая не проверяла адрес возврата хотя по спекам вроде как должнаХмм... Из какого астрала вы инфу черпаете? Ни в статье, ни в приведённой вами выше ссылки ничего подобного нет. Везде указано что ошибка связана с обработкой исключения ядром.
Про процессор я написал выше: в нём десятки флагов, влияющих на его поведение и работу. Неверная их настройка (или надежда "на авось" и отказ от их настройки с сохранением значений по умолчанию) приводят к неожидаемым ситуациям, что и случилось.
>> неспецифическое поведение sysret на процессорах Intel, которая не проверяла адрес возврата хотя по спекам вроде как должна
> Хмм... Из какого астрала вы инфу черпаете? Ни в статье, ни в
> приведённой вами выше ссылки ничего подобного нет. Везде указано что ошибка
> связана с обработкой исключения ядром.Да вот коммент из кода:
If the user-supplied value of %rip is not a canonical address, then some CPUs will trigger a ring 0 #GP during the sysret instruction. However, the fault handler would execute with the user's %gs and %rsp in ring 0 which would not be safe. Instead, preemptively kill the thread with a SIGBUS.
А в спеке такого поведения нет: http://www.nalanda.nitc.ac.in/industry/AppNotes/AMD/21086.pdf
Да и вообще неожиданное исполнение кода из юзерлянда это просто подарок.
> Про процессор я написал выше: в нём десятки флагов, влияющих на его
> поведение и работу. Неверная их настройка (или надежда "на авось" и
> отказ от их настройки с сохранением значений по умолчанию) приводят к
> неожидаемым ситуациям, что и случилось.С моей стороны это выглядит немного иначе. Изначально syscall/sysret как и sysenter/sysexit вводились чтобы заменить call/ret/iret вместе со всем набором проверок которые нужно было произвести для их вызова. А теперь получается что нет, всё равно нужно городить икебану самому потому что есть edge cases...
1. спецификации выложены на intel.com и amd.com.
2. спецификации размазаны аж по 20 (?) 500-страничным документам, где неверное прочтение любой (!!) строки может в корне повлиять на правильность результата.
3. intel и amd используют различную терминологию, поэтому правильно читать оба документа, не забывая понимать кто что под каким словом понимает.Ещё ни разу никто не уличил ни intel, ни amd в нарушении спецификаций. Если интересно - можете создать тренд на f.osdev.org и подождать, уверен вам покажут где это описано.
SYSENTER/SYSEXIT/SYSCALL/SYSRET вводились для ускоренной передачи управления между уровнями процессора и отхода от прерываний (с учётом того что прерывания сейчас через MSI, которое MMIO, это более чем логично).
Шаманство с состояниями процессора и флагами было всегда. Маскируемые прерывания, немаскируемые, исключения во время вызова обработчика прерывания, прерывание во время вызова другого прерывания, приоритет прерываний, и т.п. Почитай тот же f.osdev.org где начинающие ОС-кодеры описывают свои злоключения, там добрая треть проблем из-за настройки механизма прерываний.
>Ещё ни разу никто не уличил ни intel, ни amd в нарушении спецификаций.там вон вверху ссылка на пдф с упоминанием 121 ошибки.
специально для ваней:
Sequential Execution Across Non-Canonical Boundary
Causes Processor Hang
Description
The processor will hang when the following conditions are met:
• The processor is in 64-bit mode
• The code segment limit = 0xFFFF_FFFF
• The last byte of the current instruction is located at 0x7FFF_FFFF_FFFF
• The next sequential instruction fetch is attemped at 0x8000_0000_0000
The correct behaviour is to cause #GP (general protection exception).
Potential Effect on System
The system hangs.
Suggested Workaround
The operating system should not allocate the page at the boundary of canonical address space.так вот, это и есть нарушение спецификации. :D
> А не могли бы вы разговаривать повежливее а не на уровне пятого класса школы?Это Ваня, который гадит на форумы в обмен на наборы байтиков от MS. Как-то наивно ожидать что лох согласный делать кучу работы за право аренды вшивых байтиков будет титаном мысли. А вот уровень развития харакретный для пятиклассников - самое то что надо: несложно запудрить мозг, заставив вкалывать как папу Карло за подачки фактической себестоимостью в $0.
А то что ошибка проявляется лишь в Intel связано исключительно с ошибкой программистов, считающих частные случаи общими.Так напр. никто не обещал что при включении ПК оперативная память будет заполнена 0х00000000, хотя обычно это именно так. Никто не обещал что процессор будет в каком-то конкретном состоянии (установленные/сброшенные флаги), хотя обычно они всегда одинаковые. И т.д. "Радости" добавляет напр. что в спецификации версии 1.0 что-то было константой, а в спецификации версии 1.1 стало параметром, который нужно ещё получать по определённой методике, а в спецификации версии 1.3 изменили методику получения.
> А то что ошибка проявляется лишь в Intel связано исключительно с ошибкой
> программистов, считающих частные случаи общими.syscall/sysret изначально появился в процессорах AMD. Intel пришлось скопировать эти инструкции после выхода спецификации amd64 так как Microsoft открыто заявила что либо Intel идёт лесом со своей то-ли пятой, то-ли шестой версией 64-битных инструкций, либо берёт готовый спек от AMD.
> Так напр. никто не обещал что при включении ПК оперативная память будет
> заполнена 0х00000000, хотя обычно это именно так. Никто не обещал что
> процессор будет в каком-то конкретном состоянии (установленные/сброшенные флаги), хотя
> обычно они всегда одинаковые. И т.д. "Радости" добавляет напр. что в
> спецификации версии 1.0 что-то было константой, а в спецификации версии 1.1
> стало параметром, который нужно ещё получать по определённой методике, а в
> спецификации версии 1.3 изменили методику получения.Никто не обещал что при реализации инструкций инженеры Intel будут следовать каким-то спецификациям.
PS: Честно, я подозреваю что не в инженерах дело. Нужно было срочно выпускать новый проц чтобы поднять неосвоенную нишу рынка.
> syscall/sysret изначально появился в процессорах AMDНевежество № 1, а конкретно:
Первоначально для вызова функций ОС приложения использовали одно из 256 прерываний, которое ОС настраивала как шлюз для межуровневой передачи управления. Из-за невысокой скорости и использования механизма прерываний для вызова процедур Intel предложила пару SYSENTER/SYSEXIT.
Для х64 Intel предложила новую систему команд и архитектуру (Itanium), призванную избавиться от накопленных за долгие годы "костылей" и начать всё заново. Itanium в частности изначально расчитан на многопроцессорные системы и 64-разрядную адресацию (x86 на однопроцессорную систему, 1 Мб ОП, и 16-разрядные инструкции).
Для x64 AMD предложила надстройку над существующей архитектурой, когда для перехода в LONG MODE (native x64 mode) необходимо перевести процессор из реального режима (native 16-bit mode) в защищённый режим (native 32-bit mode), а затем в LONG MODE. Хотя есть возможность прыгнуть в LONG MODE из REAL MODE. Соотв. систему команд для x64 также придумала AMD. Команды SYSENTER/SYSEXIT были из набора команд исключены, а команды SYSCALL/SYSRET включены.
Itanium для настольных систем провалился. Причин много, и дороговизна по сравнению с предыдущими версиями процессоров, и несовместимость с написанным ПО, и относительно более медленное выполнение кода для Itanium по сравнению с существовавшими x86 процессорами, и много чего ещё.
> Intel пришлось скопировать эти инструкции после выхода спецификации amd64 так как Microsoft открыто заявила ...
Бред № 1
> Никто не обещал что при реализации инструкций инженеры Intel будут следовать каким-то спецификациям
Бред № 2
> Честно, я подозреваю что не в инженерах дело
Невежество № 2
> Нужно было срочно выпускать новый проц чтобы поднять неосвоенную нишу рынка
Бред № 3
>[оверквотинг удален]
> Для х64 Intel предложила новую систему команд и архитектуру (Itanium), призванную избавиться
> от накопленных за долгие годы "костылей" и начать всё заново. Itanium
> в частности изначально расчитан на многопроцессорные системы и 64-разрядную адресацию
> (x86 на однопроцессорную систему, 1 Мб ОП, и 16-разрядные инструкции).
> Для x64 AMD предложила надстройку над существующей архитектурой, когда для перехода в
> LONG MODE (native x64 mode) необходимо перевести процессор из реального режима
> (native 16-bit mode) в защищённый режим (native 32-bit mode), а затем
> в LONG MODE. Хотя есть возможность прыгнуть в LONG MODE из
> REAL MODE. Соотв. систему команд для x64 также придумала AMD. Команды
> SYSENTER/SYSEXIT были из набора команд исключены, а команды SYSCALL/SYSRET включены.Поздравляю, вы знаете историю. Я не стал писать сразу несколько абзацев, ограничился только константацией факта, историю которого вы нам только что рассказали.
>> Intel пришлось скопировать эти инструкции после выхода спецификации amd64 так как Microsoft открыто заявила ...
> Бред № 1А вот здесь вы плохо знаете историю. http://www.forbes.com/sites/briancaulfield/2012/02/22/how-am.../
While Intel scrambled to build its own 64-bit extensions, Microsoft forced Intel to adopt AMD’s approach, building support for AMD’s technology into its client and server software. By the end of 2006, AMD owned 25.3% of the x86 processor market. Itanium, meanwhile, has dwindled into an also-ran at the high-end of the computing market. AMD’s share price hit a post tech-bust high of $40.54 in late 2006.
>> Никто не обещал что при реализации инструкций инженеры Intel будут следовать каким-то спецификациям
> Бред № 2Ну тут уж как получилось.
>> Честно, я подозреваю что не в инженерах дело
> Невежество № 2
>> Нужно было срочно выпускать новый проц чтобы поднять неосвоенную нишу рынка
> Бред № 3По предыдущему пруф-линку:
In January of 2006 Intel began rolling out what would become a devastating response. Its ‘Core’ line of processors, designed by an obscure Israel-based processor design team led by Dadi Perlmutter sparked panic at AMD. “It was like aliens dropped the thing off,” one former AMD manager says. “It wasn’t a 1-2 punch, it was a 1-2-3-4 punch.”
Оригинал: Microsoft forced Intel to adopt AMD’s approach, building support for AMD’s technology into its client and server softwareВаша версия перевода: так как Microsoft открыто заявила что либо Intel идёт лесом со своей то-ли пятой, то-ли шестой версией 64-битных инструкций, либо берёт готовый спек от AMD.
Простите, но в оригинале сказано СОВЕРШЕННО другое.
Аналогично по второму переводу.
> Оригинал: Microsoft forced Intel to adopt AMD’s approach, building support for AMD’s
> technology into its client and server software
> Ваша версия перевода: так как Microsoft открыто заявила что либо Intel идёт
> лесом со своей то-ли пятой, то-ли шестой версией 64-битных инструкций, либо
> берёт готовый спек от AMD.
> Простите, но в оригинале сказано СОВЕРШЕННО другое.Возможно я малость и перегнул палку, но всё сводится к одному:
1. Intel выпустил Itanium. Microsoft выпустил винду под него.
2. AMD выпустила AMD64. Microsoft выпустил винду под него.
3. Intel выпустил IA-32e (по моему это так называлось, но могу сильно гнать). Когда Intel пришёл к Microsoft ему было сказано что на одну 64-bit'ную платформу от Intel винда уже портирована и начинать процесс портирования заново никто не будет.> Аналогично по второму переводу.
Это не перевод а личное мнение.
1 и 2 ДА
3 почтиИнтел продвигал Itanium, AMD продвигал AMD64. Каждый считал что за их технологией будущее, а конкурент с треском провалится. В пользу Intel'а говорило превосходство над AMD (AMD всегда был отстающим) и действительно интересная и масштабируемая аппаратная платформа, в пользу AMD - совместимость. Когда победа AMD64 стала очевидной, она была реализована Intel сначала под названием "IA32-e", затем переименована в "EMT64T", затем в "Intel64".
Майкрософт, она здесь если и была, то лишь как заинтересованное лицо (пусть и весьма влиятельное). Скорее готов допустить (форбс это всё же больше сплетни и сопли; их больше интересует стоимость акций и то что на неё влияет, чем всё прочее) что Майкрософт попросил обе компании побыстрее закончить вражду и найти компромисс. В конечном счёте необходимость х64 понимали все, вопрос стоял лишь в том какой из двух путей выбрать.
Не бойся, выдай нам свой СОВЕРШЕННО другой перевод.
> Я правильно читаю новость? В интеловских процессорах обнаружена бага которую решили считать фичей?Не-а. С куста паравиртуализации _продолжают сыпаться плоды. (И да, брат Ван +1.)
Прошла неделя. Ну, сусь вне зачета - они собс-но xen и пилят.
RHEL-5 (CentOS, SL): "This issue did not affect the versions of the kernel-xen package as shipped with Red Hat Enterprise Linux 5 as we did not have support for sysenter and compat (32bit) version of syscall instructions for PV guests..."
И ниипёт ;)Дебианщики упорно тестят патч на стабильность в сиде, а вот убунтовцы не постеснялись вкатить везде включая LTS. Что по сути верно - натягивая апдейт (и ребутая) ксено-хостинг, Вы наверное знаете, что делаете.
>>CPU AMD Athlon 64 и AMD Opteron, в которых не устранена 121 ошибка в микрокоде:D тонко так :D а почему бы рядышком на аналогичный файлик от Intel ссылочку не выложить? :D