форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+/–
Сообщение от opennews (??) on 12-Июн-12, 22:29
В гипервизоре 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.ru/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.ru/opennews/art.shtml?num=34082
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+/–
Сообщение от Аноним (??) on 12-Июн-12, 22:29
жаль нет эксплоита готового, поэкспериментировал бы на Amazon AWS
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+1 +/–
	Сообщение от Аноним (??) on 13-Июн-12, 01:48
	> жаль нет эксплоита готового, поэкспериментировал бы на Amazon AWS Сплойт может скоро появиться, а амазон вряд ли оперативно дыру прикроет.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	–3 +/–
Сообщение от Аноним (??) on 12-Июн-12, 22:53
> которая может привести к краху ядра при большой сетевой нагрузке. Greetings going to Netflix </sarcasm>.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+1 +/–
	Сообщение от Ваганыч on 13-Июн-12, 00:19
	Дружище, как бы не я не относился к бсд, но "сарказьм" надо проявлять, только поняв, для начала, о чем новость. А то выходит петросянство.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	6. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+/–
	Сообщение от Аноним (??) on 13-Июн-12, 01:46
	Судя по вашим сомнениям, вы еще не поняли.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	8. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+2 +/–
	Сообщение от Ы on 13-Июн-12, 02:18
	Мы поняли что у тебя есть шелл на Netfilx box'ах ... товариЩь пертосян :-)
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

9. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+/–
Сообщение от Аноним (??) on 13-Июн-12, 03:18
всётки опенбсдшная параноййя на стабильность + привязанность к амд сказалась , сам сижу на 32 быта и болше 4х гигов проге не даю , аппаратно , при наличии 16 оперативы , но ось их видит тока через постраничное обращение
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+1 +/–
Сообщение от arcade (ok) on 13-Июн-12, 11:34
Я правильно читаю новость? В интеловских процессорах обнаружена бага которую решили считать фичей?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+/–
	Сообщение от Ваня (??) on 13-Июн-12, 12:57
	> В гипервизоре Xen найдена критическая уязвимость ... > Проблема связана с возможностью создания условий для генерации исключения в неподходящем состоянии процессора в процессе возврата из системного вызова (SYSRET) Ошибка в Xen.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	14. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+/–
	Сообщение от arcade (ok) on 13-Июн-12, 13:23
	А почитать внимательно? http://www.securityfocus.com/archive/1/523076/30/0/threaded
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	18. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+1 +/–
	Сообщение от Ваня (??) on 13-Июн-12, 13:58
	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, т.е. в модуле обработчика исключений. Мне каждого здесь в его какашки носом тыкать??
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	20. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+/–
	Сообщение от arcade (ok) on 13-Июн-12, 14:31
	> 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, которая не проверяла адрес возврата хотя по спекам вроде как должна. > Мне каждого здесь в его какашки носом тыкать?? А не могли бы вы разговаривать повежливее а не на уровне пятого класса школы?
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	21. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+/–
	Сообщение от Ваня (??) on 13-Июн-12, 14:41
	> неспецифическое поведение sysret на процессорах Intel, которая не проверяла адрес возврата хотя по спекам вроде как должна Хмм... Из какого астрала вы инфу черпаете? Ни в статье, ни в приведённой вами выше ссылки ничего подобного нет. Везде указано что ошибка связана с обработкой исключения ядром. Про процессор я написал выше: в нём десятки флагов, влияющих на его поведение и работу. Неверная их настройка (или надежда "на авось" и отказ от их настройки с сохранением значений по умолчанию) приводят к неожидаемым ситуациям, что и случилось.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	24. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+1 +/–
	Сообщение от arcade (ok) on 13-Июн-12, 15:10
	>> неспецифическое поведение 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...
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	26. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+/–
	Сообщение от Ваня (??) on 13-Июн-12, 15:29
	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 где начинающие ОС-кодеры описывают свои злоключения, там добрая треть проблем из-за настройки механизма прерываний.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	27. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+/–
	Сообщение от ананим on 13-Июн-12, 16:08
	>Ещё ни разу никто не уличил ни 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
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	28. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+/–
	Сообщение от Аноним (??) on 13-Июн-12, 16:13
	> А не могли бы вы разговаривать повежливее а не на уровне пятого класса школы? Это Ваня, который гадит на форумы в обмен на наборы байтиков от MS. Как-то наивно ожидать что лох согласный делать кучу работы за право аренды вшивых байтиков будет титаном мысли. А вот уровень развития харакретный для пятиклассников - самое то что надо: несложно запудрить мозг, заставив вкалывать как папу Карло за подачки фактической себестоимостью в $0.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	12. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+/–
	Сообщение от Ваня (??) on 13-Июн-12, 13:02
	А то что ошибка проявляется лишь в Intel связано исключительно с ошибкой программистов, считающих частные случаи общими. Так напр. никто не обещал что при включении ПК оперативная память будет заполнена 0х00000000, хотя обычно это именно так. Никто не обещал что процессор будет в каком-то конкретном состоянии (установленные/сброшенные флаги), хотя обычно они всегда одинаковые. И т.д. "Радости" добавляет напр. что в спецификации версии 1.0 что-то было константой, а в спецификации версии 1.1 стало параметром, который нужно ещё получать по определённой методике, а в спецификации версии 1.3 изменили методику получения.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	15. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+/–
	Сообщение от arcade (ok) on 13-Июн-12, 13:26
	> А то что ошибка проявляется лишь в Intel связано исключительно с ошибкой > программистов, считающих частные случаи общими. syscall/sysret изначально появился в процессорах AMD. Intel пришлось скопировать эти инструкции после выхода спецификации amd64 так как Microsoft открыто заявила что либо Intel идёт лесом со своей то-ли пятой, то-ли шестой версией 64-битных инструкций, либо берёт готовый спек от AMD. > Так напр. никто не обещал что при включении ПК оперативная память будет > заполнена 0х00000000, хотя обычно это именно так. Никто не обещал что > процессор будет в каком-то конкретном состоянии (установленные/сброшенные флаги), хотя > обычно они всегда одинаковые. И т.д. "Радости" добавляет напр. что в > спецификации версии 1.0 что-то было константой, а в спецификации версии 1.1 > стало параметром, который нужно ещё получать по определённой методике, а в > спецификации версии 1.3 изменили методику получения. Никто не обещал что при реализации инструкций инженеры Intel будут следовать каким-то спецификациям. PS: Честно, я подозреваю что не в инженерах дело. Нужно было срочно выпускать новый проц чтобы поднять неосвоенную нишу рынка.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	16. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	–1 +/–
	Сообщение от Ваня (??) on 13-Июн-12, 13:39
	> 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
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	17. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+1 +/–
	Сообщение от arcade (ok) on 13-Июн-12, 13:58
	>[оверквотинг удален] > Для х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.”
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	19. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+/–
	Сообщение от Ваня (??) on 13-Июн-12, 14:02
	Оригинал: Microsoft forced Intel to adopt AMD’s approach, building support for AMD’s technology into its client and server software Ваша версия перевода: так как Microsoft открыто заявила что либо Intel идёт лесом со своей то-ли пятой, то-ли шестой версией 64-битных инструкций, либо берёт готовый спек от AMD. Простите, но в оригинале сказано СОВЕРШЕННО другое. Аналогично по второму переводу.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	22. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+/–
	Сообщение от arcade (ok) on 13-Июн-12, 14:49
	> Оригинал: 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 винда уже портирована и начинать процесс портирования заново никто не будет. > Аналогично по второму переводу. Это не перевод а личное мнение.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	25. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	–1 +/–
	Сообщение от Ваня (??) on 13-Июн-12, 15:17
	1 и 2 ДА 3 почти Интел продвигал Itanium, AMD продвигал AMD64. Каждый считал что за их технологией будущее, а конкурент с треском провалится. В пользу Intel'а говорило превосходство над AMD (AMD всегда был отстающим) и действительно интересная и масштабируемая аппаратная платформа, в пользу AMD - совместимость. Когда победа AMD64 стала очевидной, она была реализована Intel сначала под названием "IA32-e", затем переименована в "EMT64T", затем в "Intel64". Майкрософт, она здесь если и была, то лишь как заинтересованное лицо (пусть и весьма влиятельное). Скорее готов допустить (форбс это всё же больше сплетни и сопли; их больше интересует стоимость акций и то что на неё влияет, чем всё прочее) что Майкрософт попросил обе компании побыстрее закончить вражду и найти компромисс. В конечном счёте необходимость х64 понимали все, вопрос стоял лишь в том какой из двух путей выбрать.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	23. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+/–
	Сообщение от angra (ok) on 13-Июн-12, 14:55
	Не бойся, выдай нам свой СОВЕРШЕННО другой перевод.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	13. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+/–
	Сообщение от Andrey Mitrofanov on 13-Июн-12, 13:04
	> Я правильно читаю новость? В интеловских процессорах обнаружена бага которую решили считать фичей? Не-а. С куста паравиртуализации _продолжают сыпаться плоды. (И да, брат Ван +1.)
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

30. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+/–
Сообщение от PnD (??) on 19-Июн-12, 11:18
Прошла неделя. Ну, сусь вне зачета - они собс-но 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. Что по сути верно - натягивая апдейт (и ребутая) ксено-хостинг, Вы наверное знаете, что делаете.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

31. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+/–
Сообщение от Андрей (??) on 04-Июл-12, 13:30
>>CPU AMD Athlon 64 и AMD Opteron, в которых не устранена 121 ошибка в микрокоде :D тонко так :D а почему бы рядышком на аналогичный файлик от Intel  ссылочку не выложить? :D
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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