Омг, у меня убунта из виртуалки сбежала!

$ grep -m1 'model name' /proc/cpuinfo
model name	: AMD Phenom(tm) II X4 B45 Processor

https://bugzilla.redhat.com/show_bug.cgi?id=813428

Reported: 2012-04-17 14:30 EDT by Petr Matousek

Уже 2 месяца уязвимости, немудрено что кто-то успел патчи подготовить.

Уязвимости не подвержены операционная система Mac OS X

Ха-ха.

Да, обычного антивируса будет достаточно, чего волноваться.

Решето - ничего подобного

Ничего такого в этом на самом деле особо и нет. Да есть такая уязвимость, но они всегда и везде будут. При желании хорошая и опытная команда найдет баги и дыры в любом софте. Потому и сущетсвует такая сфера как ИБ. Другое дело насколько быстро такие дыры исправляют, и не висят ли эти багрепорты месяцами.

Is RHEL4 vulnerable? (it's still under Extended LifeCycle support).

Not vulnerable.

Statement:

This issue did not affect the versions of the Linux kernel as shipped with Red Hat Enterprise Linux 5 and 6, and Red Hat Enterprise MRG, as those versions have a guard page between the end of the user-mode accessible virtual address space and the beginning of the non-canonical area due to CVE-2005-1764 fix, and hardened system call handler due to CVE-2006-0744 fix.

This issue did affect the versions of Xen hypervisor as shipped with Red Hat Enterprise Linux 5. A kernel-xen update for Red Hat Enterprise Linux 5 is available to address this flaw.

По русски - уязвим только Xen, без вертуализации беспокоиться не о чем. Проверяющего новости на кол.

ключевое в вашей фразе - «не думаю» если бы не было так накладно, не стали бы делать аппаратную поддержку

За такой код надо вешать на первом попавшемся суку.

Что не нравится? Intel-синтакс? Если про то, что я сравниваю RCX не с константой, а с другим регистром - x86_64 мне не даёт сравнить с числом, которое нельзя упихнуть в знаковое целое 32 битное.

Что не нравится?

1. Jump должен быть только тогда когда ошибка, а не в нормальной ситуации чтобы не было проблем с branch prediction 2. Можно что-нибудь посдвигать чтобы не городить огромных констант.

Так этот баг очень старый, ему уже много лет! Либо это тот же самый с нова здорова :)

Не у приличных людей, а у любителей поразгонять

На самом деле под MacOS патча все еще нет, его сейчас в ускоренном темпе дописывают

rcx кто заведует и кто чистить будет? Не порядок же с другим регистром сравнивать

ясно. Да мне все равно. У меня x86

А почему написано Not Affected?

Хорошо что у меня Intel(R) Pentium(R) 4 CPU 2.00GHz.

rcx должен штатный код возврата заполнить, потому что sysret берёт адрес возврата из этого регистра. А вот rax стоило сохранить, да

побег из виртуальной машины

звучит как название блокбастера

у меня AMD! :P

вопрос: так эта проблема фиксится софтово? т.е. выкидывать железо не надо, просто обновление ОС, где бы все такие sysret или что там - проверялись?

Ожидал увидеть этот комментарий первым.

У Mountain Lion может быть и not affected. А патч к пердыдущим версиям макоси должен выйти с новой версией

tron 3

Феерично

Решето! Хорошо, что у меня AMD.

Кто это у тебя на аватарке?

Хидэто «Hyde» Такараи, вокалист из L’Arc~en~Ciel. J-rock же %)

написать подобный комментарий стоит выдающегося интеллекта и ума, быть может поэтому он не первый

При условии, что верхняя половина адресного пространства ядерная, вряд ли какой-либо sysret будет возвращаться туда. Так что все ветвления как раз по самой вероятной ветке - адрес меньше или равен 0x7FFFFFFFFFFF - тогда ни одного Jump не будет. Jump будет только в случае попытки заюзать дырку или очень маловероятного (возможно, вообще не допустимая, хотя и не дыра) места вызова syscall.

А еще говорят, что mac os решето.

— А под Затонью, говорят, дожди... 
— Кто говорит? 
— Мерлин говорит.©

upcFrost

Не, после бага в мускуле это уже не так смешно

Какого?

http://habrahabr.ru/post/145641/

https://rdot.org/forum/showthread.php?t=2220

freebsd как всегда отличилась

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=c...

mov rax, 0xFFFF800000000000
cmp rax, rcx
jbe lbl1
mov rax, 0x7FFFFFFFFFFF 
cmp rax, rcx
jbe lbl2
lbl1:
sysretq
lbl2:
; Код прибивания текущего процесса, потому что он сделал не то, что нужно

Всё хорошо, но только и этот код ошибочный.

1) Это Intel-синтаксис, а не AT&T.

2) Я забыл сохранять RAX

Я что-то упустил или линуксоидам не вынесли вердикт что делать и когда?

Если нужно узнать, попадает rcx в диапазон от 0x7FFFFFFFFFFF до 0xFFFF800000000000, сделай так: mov rax, rcx sub rax, 0x7FFFFFFFFFFF cmp rax, 0xFFFF800000000000 - 0x7FFFFFFFFFFF И всё! Ещё бы я вообще запихал 0x7FFFFFFFFFFF в rbx, например, а потом использовал инструкцию not, поскольку понятно, что константы комплементарны, но это уже немного изврат :)

1) Это Intel-синтаксис, а не AT&T.

По мне, так это как раз хорошо

комплИментарны

+1

Дело даже не в оверклокинге. Назойливая реклама и агрессивный маркетинг парней из Санта-Клары у многих вызывала вполне объяснимое отторжение.

Сдаётся мне, что всё же комплементарны

Потом как-то обновлять микрокод? Ну же, специалисты, разъясните толково!

С Intel здесь всё просто.

# /etc/init.d/microcode_ctl start

Сколько процессоров успели продать?

Да, в английском же complementary. В последнее время сомневаюсь в себе даже по самым элементарным поводам.

Может быть, они эту дырку намеренно пропустили, мир захватывать?

Причем половина 15-строчного патча - это комментарий. Оно и понятно: хорошая архитектура = дешёвое изменение кода...

дайте два сплоета

Когда? Прям щас? А когда тогда, чего дожидаться? Что устанавливать? Ядро обновлять? Я же попросил ТОЛКОВО!