| |
| 2.7, Аноним (-), 01:48, 13/06/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> жаль нет эксплоита готового, поэкспериментировал бы на Amazon AWS
Сплойт может скоро появиться, а амазон вряд ли оперативно дыру прикроет.
| | |
|
| 1.2, Аноним (-), 22:53, 12/06/2012 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– | |
> которая может привести к краху ядра при большой сетевой нагрузке.
Greetings going to Netflix </sarcasm>.
| | |
| |
| 2.4, Ваганыч (?), 00:19, 13/06/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Дружище, как бы не я не относился к бсд, но "сарказьм" надо проявлять, только поняв, для начала, о чем новость. А то выходит петросянство.
| | |
| |
| |
| 4.8, Ы (?), 02:18, 13/06/2012 [^] [^^] [^^^] [ответить]
| +2 +/– |
Мы поняли что у тебя есть шелл на Netfilx box'ах ... товариЩь пертосян :-)
| | |
|
|
|
| 1.9, Аноним (9), 03:18, 13/06/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 всётки опенбсдшная параноййя на стабильность + привязанность к амд сказалась , сам сижу на 32 быта и болше 4х гигов проге не даю , аппаратно , при наличии 16 оперативы , но ось их видит тока через постраничное обращение
| | |
| 1.10, arcade (ok), 11:34, 13/06/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 Я правильно читаю новость? В интеловских процессорах обнаружена бага которую решили считать фичей?
| | |
| |
| 2.11, Ваня (??), 12:57, 13/06/2012 [^] [^^] [^^^] [ответить]
| +/– |
> В гипервизоре Xen найдена критическая уязвимость ...
> Проблема связана с возможностью создания условий для генерации исключения в неподходящем состоянии процессора в процессе возврата из системного вызова (SYSRET)
Ошибка в Xen.
| | |
| |
| |
| 4.18, Ваня (??), 13:58, 13/06/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
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, т.е. в модуле обработчика исключений.
Мне каждого здесь в его какашки носом тыкать??
| | |
| |
| 5.20, arcade (ok), 14:31, 13/06/2012 [^] [^^] [^^^] [ответить]
| +/– |
> 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, которая не проверяла адрес возврата хотя по спекам вроде как должна.
> Мне каждого здесь в его какашки носом тыкать??
А не могли бы вы разговаривать повежливее а не на уровне пятого класса школы?
| | |
| |
| 6.21, Ваня (??), 14:41, 13/06/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> неспецифическое поведение sysret на процессорах Intel, которая не проверяла адрес возврата хотя по спекам вроде как должна
Хмм... Из какого астрала вы инфу черпаете? Ни в статье, ни в приведённой вами выше ссылки ничего подобного нет. Везде указано что ошибка связана с обработкой исключения ядром.
Про процессор я написал выше: в нём десятки флагов, влияющих на его поведение и работу. Неверная их настройка (или надежда "на авось" и отказ от их настройки с сохранением значений по умолчанию) приводят к неожидаемым ситуациям, что и случилось.
| | |
| |
| 7.24, arcade (ok), 15:10, 13/06/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> неспецифическое поведение 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...
| | |
| |
| 8.26, Ваня (??), 15:29, 13/06/2012 [^] [^^] [^^^] [ответить] | +/– | 1 спецификации выложены на intel com и amd com 2 спецификации размазаны аж по... текст свёрнут, показать | | |
| |
| 9.27, ананим (?), 16:08, 13/06/2012 [^] [^^] [^^^] [ответить] | +/– | там вон вверху ссылка на пдф с упоминанием 121 ошибки специально для ваней Seq... текст свёрнут, показать | | |
|
|
|
| 6.28, Аноним (-), 16:13, 13/06/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> А не могли бы вы разговаривать повежливее а не на уровне пятого класса школы?
Это Ваня, который гадит на форумы в обмен на наборы байтиков от MS. Как-то наивно ожидать что лох согласный делать кучу работы за право аренды вшивых байтиков будет титаном мысли. А вот уровень развития харакретный для пятиклассников - самое то что надо: несложно запудрить мозг, заставив вкалывать как папу Карло за подачки фактической себестоимостью в $0.
| | |
|
|
|
|
| 2.12, Ваня (??), 13:02, 13/06/2012 [^] [^^] [^^^] [ответить]
| +/– | |
А то что ошибка проявляется лишь в Intel связано исключительно с ошибкой программистов, считающих частные случаи общими.
Так напр. никто не обещал что при включении ПК оперативная память будет заполнена 0х00000000, хотя обычно это именно так. Никто не обещал что процессор будет в каком-то конкретном состоянии (установленные/сброшенные флаги), хотя обычно они всегда одинаковые. И т.д. "Радости" добавляет напр. что в спецификации версии 1.0 что-то было константой, а в спецификации версии 1.1 стало параметром, который нужно ещё получать по определённой методике, а в спецификации версии 1.3 изменили методику получения.
| | |
| |
| 3.15, arcade (ok), 13:26, 13/06/2012 [^] [^^] [^^^] [ответить]
| +/– |
> А то что ошибка проявляется лишь в Intel связано исключительно с ошибкой
> программистов, считающих частные случаи общими.
syscall/sysret изначально появился в процессорах AMD. Intel пришлось скопировать эти инструкции после выхода спецификации amd64 так как Microsoft открыто заявила что либо Intel идёт лесом со своей то-ли пятой, то-ли шестой версией 64-битных инструкций, либо берёт готовый спек от AMD.
> Так напр. никто не обещал что при включении ПК оперативная память будет
> заполнена 0х00000000, хотя обычно это именно так. Никто не обещал что
> процессор будет в каком-то конкретном состоянии (установленные/сброшенные флаги), хотя
> обычно они всегда одинаковые. И т.д. "Радости" добавляет напр. что в
> спецификации версии 1.0 что-то было константой, а в спецификации версии 1.1
> стало параметром, который нужно ещё получать по определённой методике, а в
> спецификации версии 1.3 изменили методику получения.
Никто не обещал что при реализации инструкций инженеры Intel будут следовать каким-то спецификациям.
PS: Честно, я подозреваю что не в инженерах дело. Нужно было срочно выпускать новый проц чтобы поднять неосвоенную нишу рынка.
| | |
| |
| 4.16, Ваня (??), 13:39, 13/06/2012 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> 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
| | |
| |
| 5.17, arcade (ok), 13:58, 13/06/2012 [^] [^^] [^^^] [ответить] | +1 +/– | gt оверквотинг удален Поздравляю, вы знаете историю Я не стал писать сразу не... большой текст свёрнут, показать | | |
| |
| 6.19, Ваня (??), 14:02, 13/06/2012 [^] [^^] [^^^] [ответить]
| +/– | |
Оригинал: Microsoft forced Intel to adopt AMD’s approach, building support for AMD’s technology into its client and server software
Ваша версия перевода: так как Microsoft открыто заявила что либо Intel идёт лесом со своей то-ли пятой, то-ли шестой версией 64-битных инструкций, либо берёт готовый спек от AMD.
Простите, но в оригинале сказано СОВЕРШЕННО другое.
Аналогично по второму переводу.
| | |
| |
| 7.22, arcade (ok), 14:49, 13/06/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Оригинал: 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 винда уже портирована и начинать процесс портирования заново никто не будет.
> Аналогично по второму переводу.
Это не перевод а личное мнение.
| | |
| |
| 8.25, Ваня (??), 15:17, 13/06/2012 [^] [^^] [^^^] [ответить] | –1 +/– | 1 и 2 ДА 3 почти Интел продвигал Itanium, AMD продвигал AMD64 Каждый считал что... текст свёрнут, показать | | |
|
|
|
|
|
|
| 2.13, Andrey Mitrofanov (?), 13:04, 13/06/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Я правильно читаю новость? В интеловских процессорах обнаружена бага которую решили считать фичей?
Не-а. С куста паравиртуализации _продолжают сыпаться плоды. (И да, брат Ван +1.)
| | |
|
| 1.30, PnD (??), 11:18, 19/06/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Прошла неделя. Ну, сусь вне зачета - они собс-но 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. Что по сути верно - натягивая апдейт (и ребутая) ксено-хостинг, Вы наверное знаете, что делаете.
| | |
| 1.31, Андрей (??), 13:30, 04/07/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>>CPU AMD Athlon 64 и AMD Opteron, в которых не устранена 121 ошибка в микрокоде
:D тонко так :D а почему бы рядышком на аналогичный файлик от Intel ссылочку не выложить? :D
| | |
|
