SO> Sergey Okhapkin (Sergey.Okhapkin@f50.n5020.z2.fidonet.org) wrote:
SO> Hi everyone,
SO> I just confirmed that disabling the 1st Level Cache (as someone
SO> suggested here) in the BIOS (if it offers that option) makes at least
SO> Windows NT 4.0 immune against the F0-attack. You can leave the 2nd
SO> level Cache enabled.
SO> Of course, this makes NT run at a crawl..
да, теперь это стало это понятно и из теоретических соображений. по
последним данным и (немного) моим их обдумываниям, механизм весьма
прост - сначала lock лочит шину, а только потом декодер команд
добирается до неправильного байта в инструкции и пытается вызвать
обработчик иксепшена. и, если idt entry (не уверен за это, может
быть самого кода) того нет в данный момент в l1-кэше, то все взвисает,
потому что до l2-кэша/памяти при залоченой шине проц добраться уже не
может. в качестве проверки можно попробовать подставить любое другое
вместо eax,ecx - должно быть то же самое. а почему другие процы не
подвержены - тоже понятно, значит у них либо больше глубина
декодирования и декодер успевает обнаружить ошибку раньше, чем
исполнительное устройство залочит шину, или у них другой механизм
отработки lock, типа "ничего не лочить, пока не будет декодирована вся
инструкция целиком". это же об'ясняет и нерегулярность повторяемости
этого бага под win95 - значит в чукаке регулярно _штатно_ происходит
исполнение инвалидных инструкций (зачем, интересно?;) и обработчик этого
иксепшена не вылезает из l1-кэша. я чукакских потрохов не знаю, это лишь
теоретическое предположение. попробовать немного защититься от этого дела
под линуксом (под ним, потому что только от него у меня есть сорсы;),
например, можно с помощью попытки удержать нужные данные в l1, читая их
из таймерного прерывания (1KHz, вроде?). в таком случае есть шанс
(вероятность котрого мне сложно оценить на глаз), что тело обработчика
окажется в l1 и ничего страшного не случится. сейчас похачу ядро и
проверю.
p.s. похачил, перегружаюсь. не поминайте лихом ;-)
-- C U ! Mad Max / Queue Members Group -- end of forwarded message --
--
Kittle