Уязвимость в реализации инструкции SYSRET всех выпущенных x86-64 процессоров Intel

странно, что несмотря на этот патч шестилетней давности, написано что ядро linux всё равно подвержено этому багу...

Я не знаю, готово ли обновление микрокода, исправляющее данный баг. Под линукс есть пакет microcode-ctl

$ eix sys-apps/microcode-ctl
[I] sys-apps/microcode-ctl
     Available versions:  1.17-r2
     Installed versions:  1.17-r2(20:54:44 17.06.2012)
     Homepage:            http://www.urbanmyth.org/microcode
     Description:         Intel processor microcode update utility

Последняя, доступная в Gentoo, версия микрокода:

$ eix sys-apps/microcode-data
[I] sys-apps/microcode-data
     Available versions:  20100209 20101123 (~)20110428 (~)20110915 (~)20110915-r1 (~)20111110 (~)20120606
     Installed versions:  20120606(20:54:34 17.06.2012)
     Homepage:            http://urbanmyth.org/microcode/
     Description:         Intel IA32 microcode update data

Так же обновлением микрокода занимается BIOS во время POST.

создание такой инструкции как SYSENTER - плевок на собственную архитектуру, основа которой заложена в 80286

Так же обновлением микрокода занимается BIOS во время POST.

Он этот микрокод из прошивки BIOS должен брать, а в прошику BIOS кто этот микрокод положит?

Производитель матери.

Производитель матери.

Он обязательно это сделает, ему это очень надо!

Я и не говорил, что надо ждать обновления BIOS с фиксом бага в микрокоде.

таки насколько я понял, подвержен только xen, а не ванилла линукс

как будто за тобой Anonymous охотится

в 64-х битном режиме работы процессоров Intel

Интел не нужен

Уязвимости не подвержены операционная система Mac OS X и виртуальная машина VMWare.

Звучит как реклама.

Ещё VAMPS. Ты умничка ^_^

Матрица в опасности? :)

Anonymous

раздутая ересь из сми :(

x86_64 мне не даёт сравнить с числом, которое нельзя упихнуть в знаковое целое 32 битное.

Можно с этого места подробней?

создание такой инструкции как SYSENTER - плевок на собственную архитектуру, основа которой заложена в 80286

Почему?

Уязвимости не подвержены операционная система Mac OS X и виртуальная машина VMWare.

Скорее в VMWare машину с Mac OS X!

«Побег из Виртуальной Машины».

Сколько котят пострадало в ходе съемок?

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

Надо скорей переходить на маки.

ха, как знал, вчера поставил OS X в соседи генте, кстати ничо так система, первое впечатление хорошее

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

Капец, все сбегут.

x86 нужно было закопать двадцать лет назад.

Создание 80386 - плевок на архитектуру 80286, а создание amd64 - окончательное ее закапывание.

[kiv@kiv-notebook ~]$ cat test.asm
use64
	cmp rax, 0
	cmp rax, 0x1000
	cmp rax, 0x7FFFFFFF
	cmp rax, 0x80000000
[kiv@kiv-notebook ~]$ fasm test.asm
flat assembler  version 1.70.02  (16384 kilobytes memory)
test.asm [5]:
	cmp rax, 0x80000000
error: value out of range.
[kiv@kiv-notebook ~]$ cat test2.asm
use64
	cmp rax, qword 0x80000000
[kiv@kiv-notebook ~]$ fasm test2.asm
flat assembler  version 1.70.02  (16384 kilobytes memory)
test2.asm [2]:
	cmp rax, qword 0x80000000
error: not encodable with long immediate.

Ошибка возникает при попытке использовать в операциях типа cmp, add, sub и т. п. непосредственное значение, которое можно уложить в знаковое 32-битное целое. Какой-нибудь 0xFFFFFFFF80000000 получится, потому что его можно уместить в 32 бита, а потом просто расширить знак до 64-х (это уже делает процессор).

как хорошо что у меня 99% на VMWare ))))

Странно, с GNU asm такой проблемы не наблюдается. Во всяком случае я не видел.

Он точно генерирует одну инструкцию? Просто поддерржка x86_64 в fasm появилась давно и было не мало фиксов. Такой очевидный баг не могли не заметить.

В топку AMD это не процессоры, а утюги

Такое было еще в первом пентиуме ЕМНИП.

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

архитектура = дешёвое изменение кода...

So true :) В линуксе патч - *две* строки кода ;)

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

в gas та же ошибка, а для 0xFFFFFFFF80000000 он делает приведение к 32 бит, и забавно что с 32-бит регистрами работает:

  4004b4:       05 00 00 00 80          add    $0x80000000,%eax
  4004b9:       48 05 ff ff ff 7f       add    $0x7fffffff,%rax
  4004bf:       48 05 00 00 00 80       add    $0xffffffff80000000,%rax

В линуксе патч - *две* строки кода ;)

А почему *две* строки кода оказались раскиданы по *4* файлам в приведенном патче ? Типа, говнокод из 4 файлов выкинули, код в 2 файла вставили? Иронически улыбаюсь вместе с тобой.

А с русским языком у них беда, такое впечатление что промпт переводил а потом пьяный манагер немного подправил.

Злорадные пользователи обогревателей процессоров AMD передают вам пламенный привет.

Не ошибается тот, кто ничего не делает... Может товарищу чем нибудь заняться? И тогда и у него будут ошибки многолетние)))

по *4* файлам

ну и где там 4 файла?

А почему *две* строки кода оказались раскиданы по *4* файлам в приведенном патче ?

Потому что не оказались.

Типа, говнокод из 4 файлов выкинули, код в 2 файла вставили?

Нет. Захотите выкинуть говнокод - пишите. Примут - можете выкидывать.

Иронически улыбаюсь вместе с тобой.

А, то есть это была шутка и патчи читать ты умеешь?.. Не верю.

еще проще можно сделать:

mov rax, 0x7FFFFFFFFFFF
cmp rax, rcx
setb al
movsx rax, al
sysretq

тьфу опечатка

mov rax, 0x7FFFFFFFFFFF
cmp rax, rcx
setb al
movsx rax, al
and rcx,rax
sysretq

что-то я уже туплю)

setb al, сделает al = 0, либо al = 1. movsx расширяет знак байта. поскольку и у 0 и у 1 знаковый бит сброшен, в итоге rax так и равен либо нулю, либо единице.

И этот and либо вообще сотрёт значение rcx, либо оставит последний бит.

таким образом rcx ставит некорректным в любом случае. вопрос: нафига?

и да, стоит вспомнить про push rax в начале и pop rax в конце, потому что в нём возвращается результат системного вызова и не стоит его затирать.

setb сделает 0xff в al. вроде бы

Что любопытно, дамы и господа: http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=21385&...

Имя файла: microcode-20120606.tgz

Версия: 20120606

Дата: 06.06.2012

Состояние: Последнее

Распаковываем, запускаем апдейт и видим:

microcode: CPU0 sig=0x10676, pf=0x1, revision=0x60c

microcode: CPU1 sig=0x10676, pf=0x1, revision=0x60c

microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

microcode: CPU0 updated to revision 0x60f, date = 2010-09-29

microcode: CPU1 updated to revision 0x60f, date = 2010-09-29

Получается, в Intel не только знали о баге, но уже и исправление подготовили еще в конце сентября 2010 года? А опубликовали только после того, как о дырке стало известно публично...

Peter Oruba
tigran@aivazian.fsnet.co.uk
ВТФ? И почему aivazian.fsnet.co.uk ведет на движение живого иисуса?

При этом линупсоиды знали чёрт знает когда. Действительно, эпично :)

Не стали заниматься ненужными мелочами. Те кто юзают Винду так или иначе под колпаком. Это гарантировано законодательством США.

пламенный привет

Вы хотели сказать «плазменный»?

В Ubuntu, если установлены пакеты intel-microcode и microcode.ctl

# update-intel-microcode

successfully downloaded Intel 20120606 microcode

наблюдаем в сислоге:

microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x26
microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x26
microcode: CPU2 sig=0x206a7, pf=0x2, revision=0x26
microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x26
microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
microcode: CPU0 updated to revision 0x28, date = 2012-04-24
microcode: CPU1 updated to revision 0x28, date = 2012-04-24
microcode: CPU2 updated to revision 0x28, date = 2012-04-24
microcode: CPU3 updated to revision 0x28, date = 2012-04-24

Получается, в Intel не только знали о баге, но уже и исправление подготовили еще в конце сентября 2010 года? А опубликовали только после того, как о дырке стало известно публично...

проц i5-2500 с 26 ревизией. Интересно что пофиксили в 27 и 28?