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

Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..., opennews (??), 12-Июн-12, (0) [смотреть все] жаль нет эксплоита готового, поэкспериментировал бы на Amazon AWS, Аноним (-), 22:29 , 12-Июн-12, (1) // Сплойт может скоро появиться, а амазон вряд ли оперативно дыру прикроет , Аноним (-), 01:48 , 13-Июн-12, (7) +1 Greetings going to Netflix sarcasm , Аноним (-), 22:53 , 12-Июн-12, (2) –3 // Дружище, как бы не я не относился к бсд, но сарказьм надо проявлять, только по, Ваганыч (?), 00:19 , 13-Июн-12, (4) +1 // Судя по вашим сомнениям, вы еще не поняли , Аноним (-), 01:46 , 13-Июн-12, (6) // Мы поняли что у тебя есть шелл на Netfilx box ах товариЩь пертосян - , Ы (?), 02:18 , 13-Июн-12, (8) +2 всётки опенбсдшная параноййя на стабильность привязанность к амд сказалась , с, Аноним (9), 03:18 , 13-Июн-12, (9) Я правильно читаю новость В интеловских процессорах обнаружена бага которую реш, arcade (ok), 11:34 , 13-Июн-12, (10) +1 // Ошибка в Xen , Ваня (??), 12:57 , 13-Июн-12, (11) // А почитать внимательно http www securityfocus com archive 1 523076 30 0 threa, arcade (ok), 13:23 , 13-Июн-12, (14)   // II Problem DescriptionFreeBSD amd64 runs on CPUs from different vendors Due to, Ваня (??), 13:58 , 13-Июн-12, (18) +1   Да, именно об этом был мой вопрос И в Xen, и в FreeBSD фиксили неспецифическое , arcade (ok), 14:31 , 13-Июн-12, (20)   Хмм Из какого астрала вы инфу черпаете Ни в статье, ни в приведённой вами вы, Ваня (??), 14:41 , 13-Июн-12, (21)   Да вот коммент из кода If the user-supplied value of rip is not a canonical add, arcade (ok), 15:10 , 13-Июн-12, (24) +1   1 спецификации выложены на intel com и amd com 2 спецификации размазаны аж по , Ваня (??), 15:29 , 13-Июн-12, (26)   там вон вверху ссылка на пдф с упоминанием 121 ошибки специально для ваней Seque, ананим (?), 16:08 , 13-Июн-12, (27)   Это Ваня, который гадит на форумы в обмен на наборы байтиков от MS Как-то наивн, Аноним (-), 16:13 , 13-Июн-12, (28)   А то что ошибка проявляется лишь в Intel связано исключительно с ошибкой програм, Ваня (??), 13:02 , 13-Июн-12, (12) // syscall sysret изначально появился в процессорах AMD Intel пришлось скопировать, arcade (ok), 13:26 , 13-Июн-12, (15) // Невежество 8470 1, а конкретно Первоначально для вызова функций ОС приложения, Ваня (??), 13:39 , 13-Июн-12, (16) –1 gt оверквотинг удален Поздравляю, вы знаете историю Я не стал писать сразу не, arcade (ok), 13:58 , 13-Июн-12, (17) +1 Оригинал Microsoft forced Intel to adopt AMD 8217 s approach, building support, Ваня (??), 14:02 , 13-Июн-12, (19) Возможно я малость и перегнул палку, но всё сводится к одному 1 Intel выпустил, arcade (ok), 14:49 , 13-Июн-12, (22) 1 и 2 ДА3 почтиИнтел продвигал Itanium, AMD продвигал AMD64 Каждый считал что з, Ваня (??), 15:17 , 13-Июн-12, (25) –1 Не бойся, выдай нам свой СОВЕРШЕННО другой перевод , angra (ok), 14:55 , 13-Июн-12, (23) Не-а С куста паравиртуализации _продолжают сыпаться плоды И да, брат Ван 1 , Andrey Mitrofanov (?), 13:04 , 13-Июн-12, (13) Прошла неделя Ну, сусь вне зачета - они собс-но xen и пилят RHEL-5 CentOS, S, PnD (??), 11:18 , 19-Июн-12, (30) D тонко так D а почему бы рядышком на аналогичный файлик от Intel ссылочку не, Андрей (??), 13:30 , 04-Июл-12, (31) 1,2,9,10,30,31

Сообщения

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

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

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

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

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

	24. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+1 +/–
	Сообщение от arcade (ok), 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...
	Ответить | Правка | Наверх | Cообщить модератору

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

	27. "Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разр..."	+/–
	Сообщение от ананим (?), 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
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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