При бесплатном обновлении с Windows 7/8.1 на Windows 10 активация привязывается к Вашему железу. Новый ключ при этом не выдаётся, в обновлённой системе пропишется один из общих ключей. При чистой установке Windows 10 на ту систему, на которой уже было сделано обновление с предыдущих версий Windows, ключ вводить не требуется. Система активируется автоматически.
Минимальные системные требования
• Процессор:Не менее 1 ГГц или SoC • ОЗУ: 1 ГБ (для 32-разрядных систем) или 2 ГБ (для 64-разрядных систем) • Место на жестком диске: 16 ГБ (для 32-разрядных систем) или 20 ГБ (для 64-разрядных систем) • Видеокарта: DirectX версии 9 или выше с драйвером WDDM 1.0 • Дисплей: 800 x 600
Ссылка на ISO образы Windows 10 c сайта Microsoft (Выбираете просто Windows 10 - это самая стандартная версия, включает Pro и Home x32&x64, остальные урезанные...)
После обновления с Windows 7 или 8.1 для корректной работы Windows 10 желательно переустановить основные драйвера в системе на актуальные версии. Обновление драйверов чипсета на последнюю версию может помочь устранить ошибки в системном журнале Windows, если таковые имеются. Для материнских плат на чипсете Intel последнюю версию Intel Chipset Driver можно скачать здесь, или версию 10.1.1.9 c сайта Gigabyte здесь. Для AMD - здесь.
При бесплатном обновлении с Windows 7/8.1 на Windows 10 активация привязывается к Вашему железу. Новый ключ при этом не выдаётся, в обновлённой системе пропишется один из общих ключей. Обновляться можно как через резервирование обновления и Windows Update, так и с помощью Media Creation Tool, образ скачивается тот же. При чистой установке Windows 10 на ту систему, на которой уже было сделано обновление с предыдущих версий Windows, ключ вводить не требуется. Система активируется автоматически.
Оставляете все настройки в BIOS, а также не отключаете никакие диски - ставите 10-ку, загрузившись с её установочного носителя. В результате у вас должно появиться меню с выбором системы для загрузки. Если приоритетной или последней перед перезагрузкой была 7-ка, то этот выбор ОС будет в старом классическом стиле с белыми буквами на чёрном фоне и перемещаемой полоской выбора. Если же в дефолте загрузка 10-ки или вы перезагружаетесь с 10-ки, то выбор ОС будет на голубом фоне, названия ОС будут в "плитках", курсор мыши вроде бы доступен - уже не помню. Если перезагрузиться с 10-ки и снова её выбрать, получив выбор ОС на голубом фоне, то происходит обычная дальнейшая загрузка 10-ки. Если же выбрать 7-ку, то сначала произойдёт автоматическая перезагрузка компьютера, а потом 7-ка будет сразу загружаться без каких-либо запросов. Если ваши установленные ОС нормальные, без искажённых загрузчиков и не затвиканы до смерти, то никаких проблем с данным выбором ОС нет и не будет.
У кого стоит Масштабирование х125% (не стандартное х100%) и проблема с замыливанием некоторых окон! "В Windows 10 и Windows 8.1 используется новая методика масштабирования отображаемых на дисплее шрифтов. Существует возможность вернуться к старому методу масштабирования, используемого в Windows 8 RTM и Windows 7. В большинстве случаев это поможет решить проблему размытости и некорректного отображения шрифтов. 1.Создайте файл revert_classic_dpi.bat со следующим текстом: REG ADD "HKCU\Control Panel\Desktop" /v DpiScalingVer /t REG_DWORD /d 0x00001018 /f REG ADD "HKCU\Control Panel\Desktop" /v Win8DpiScaling /t REG_DWORD /d 0x00000001 /f REG ADD "HKCU\Control Panel\Desktop" /v LogPixels /t REG_DWORD /d 0x00000078 /f 2.Запустите файл revert_classic_dpi.bat с правами администратора. 3.Перезагрузите Windows 10 4.Проверьте, исправилась ли проблема с отображением шрифтов Примечание. В некоторых случаях значение ключа DpiScalingVer при выходе из системы каждый раз возвращалось на 1000. Надо скопировать созданный bat файл в автозагрузку (Win+R -> shell:startup) и ещё раз перезагрузить компьютер."
В этой теме обсуждаются технические вопросы
Обсудить нетехнические вопросы, обсудить шпионаж новой ОС, пофлеймить, сравнить с Windows XP (7, 8, 8.1...) и просто поболтать можно здесь Любой флейм или попытка спровоцировать холивар в теме приведут к ЖК и запрету на участие в теме. Нарушение запрета - к бану.
Ссылки на образы или места, где их можно достать, считаются нарушением п. 3.17 правил конференции, если только идентичный образ не был выложен официально Microsoft в открытый (не требующий регистрации, ключей или подписок) доступ. То же самое касается и ключей. Советы/рекомендации по установке редакций, доступных только в рамках корпоративного лицензирования, рассматриваются отдельно и могут быть классифицированы как нарушение 3.17. Активация сама по себе не легализует (не превращает в лицензионную) установленную копию Windows. Обсуждение (а тем более поддержка/пропаганда) методов получения активированной копии без ее приобретения (за исключением действующих программ обновления с легально приобретенных копий предыдущих версий лицами, подпадающими под действие этих программ) не приветствуется.
Последний раз редактировалось 4e_alex 21.08.2017 15:07, всего редактировалось 53 раз(а).
Member
Статус: Не в сети Регистрация: 16.02.2016 Откуда: Рідна ненька Фото: 14
kiberman писал(а):
а Амд положить болт на Meltdown-у неё этих проблем не
исследователи говорят что amd и arm процессоры потенциально уязвимы для meltdown. Но PoC для интела на них не работает, а копать они не стали, хотя всё указывает на возможность атаки.
iG0Lka писал(а):
исходя из того что будет меняться механизм работы ядра системы возникают сомнения...
На винде ничего особо меняться не будет. Просто меньше кишков будут мапить в виртуальное адресное пространство процесса. А вот в линупсе там полная писечка из-за этого бага. Эти красавцы умудрились замапить всю физическую память, что ставит под удар PV сходу.
Advanced member
Статус: Не в сети Регистрация: 16.05.2010 Откуда: Ленинград Фото: 559
woody писал(а):
сследователи говорят что amd и arm процессоры потенциально уязвимы для meltdown. Но PoC для интела на них не работает, а копать они не стали, хотя всё указывает на возможность атаки.
Как сообщают специалисты, уязвимости Meltdown подвержены все процессоры Intel с поддержкой исполнения команд с изменением последовательности (out-of-order execution). Это почти все чипы, выпущенные с 1995 года за исключением серии Itanium целиком и чипов Atom до 2013 года. В настоящее время нет подтверждений о том, что процессоры ARM и AMD подвержены Meltdown.
Member
Статус: Не в сети Регистрация: 16.02.2016 Откуда: Рідна ненька Фото: 14
kiberman писал(а):
О каких исследователях речь?
Об оригинальных, тех что нашли багу, задокументировали, написали рабочий PoC, разослали всем заинтересованным и тому подобное. Вот что они пишут:
Цитата:
6.4 Limitations on ARM and AMD We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD. The reasons for this can be manifold. First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow out-of-order execution pipeline could tip the race condition towards against the data leakage. Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able to leak data. However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.
Member
Статус: Не в сети Регистрация: 16.06.2013 Фото: 17
kiberman писал(а):
Хотя Линус трагедии в связи с Амд не делает
Зато по Интелу прошёлся здорово
Торвальдс
From Linus Torvalds <> Date Wed, 3 Jan 2018 15:51:35 -0800 Subject Re: Avoid speculative indirect calls in kernel
On Wed, Jan 3, 2018 at 3:09 PM, Andi Kleen <andi@firstfloor.org> wrote: > This is a fix for Variant 2 in > https://googleprojectzero.blogspot.com/ ... -side.html > > Any speculative indirect calls in the kernel can be tricked > to execute any kernel code, which may allow side channel > attacks that can leak arbitrary kernel data.
Why is this all done without any configuration options?
A *competent* CPU engineer would fix this by making sure speculation doesn't happen across protection domains. Maybe even a L1 I$ that is keyed by CPL.
I think somebody inside of Intel needs to really take a long hard look at their CPU's, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.
.. and that really means that all these mitigation patches should be written with "not all CPU's are crap" in mind.
Or is Intel basically saying "we are committed to selling you shit forever and ever, and never fixing anything"?
Because if that's the case, maybe we should start looking towards the ARM64 people more.
Please talk to management. Because I really see exactly two possibibilities:
- Intel never intends to fix anything
OR
- these workarounds should have a way to disable them.
Which of the two is it?
Linus
_________________ Ryzen 7 5800X + 32 ГБ ОЗУ + RX 6700 XT + Full HD
Advanced member
Статус: Не в сети Регистрация: 16.05.2010 Откуда: Ленинград Фото: 559
woody писал(а):
Meltdown штука аппаратная и от системы/ядра не зависит.
да но я сижу на окнах и ядро там другое и менеджмент памяти другой,включая механизмы получение прав и написание эксплоитов.
woody писал(а):
Но всё может поменяться. Выше я выделил почему.
если такой Авторитет как Линус удалил часть кода и запретил патч на Амд. Видимо ему виднее,что ничего не поменяется-с чего бы это?
Добавлено спустя 2 минуты 6 секунд:
mphuZ писал(а):
Зато по Интелу прошёлся здорово
Да пнул он их от души,а те отмалчиваются,с падением акций на биржах. У меня вобще мысль что или лазейку анбшную кроют или ещё чего-где-то выплыло из канализации вся подноготная .
Member
Статус: Не в сети Регистрация: 16.02.2016 Откуда: Рідна ненька Фото: 14
kiberman писал(а):
если такой Авторитет как Линус удалил часть кода и запретил патч на Амд. Видимо ему виднее,что ничего не поменяется-с чего бы это?
Вот для тех кто читать не умеет я скопирую ещё раз:
Цитата:
However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.
Мнение Линуса для нас конечно ценно, но всё же лучше прислушаться с исследователями сего бага, которые всё же не так категоричны в своих суждениях.
kiberman писал(а):
У меня вобще мысль что или лазейку анбшную кроют или ещё чего-где-то выплыло из канализации вся подноготная
Ох, теории заговора пошли. mov внутри разбивается на два мю-опса: fetch и check. И в этот момент возникает гонка, задача выполнить fetch плюс ещё кусочек кода до того как будет выполнена проверка прав доступа. А потом уже простая time attach против кеша чтобы узнать что же мы достали из памяти. Больше выглядит как оптимизация, чем "лазейка", тем более что работает "баг" только в рамках виртуального адресного пространства текущего процесса.
Advanced member
Статус: Не в сети Регистрация: 16.05.2010 Откуда: Ленинград Фото: 559
woody писал(а):
Вот для тех кто читать не умеет я скопирую ещё раз:
Теперь найдите мне в тексте какой конкретно процессор Амд-модель. Мне лень эту всю простыню читать как они обошли проверку прав доступа? в юзер режиме они бы не смогли этого сделать на амд.
Member
Статус: Не в сети Регистрация: 16.02.2016 Откуда: Рідна ненька Фото: 14
kiberman писал(а):
Мне лень эту всю простыню читать как они обошли проверку прав доступа?
а на 3dnews не написали разве?
Код:
; rcx = a protected kernel memory address ; rbx = address of a large array in user space mov al, byte [rcx] ; read from forbidden kernel address shl rax, 0xc ; multiply the result from the read operation with 4096 mov rbx, qword [rbx + rax] ; touch the user space array at the offset that we just calculated
Этот код скармливают процессору, либо напрямую через TSX, либо через branch prediction, в общем важно чтобы он был спекулятивно выполнен. В результате часть массива, на который изначально указывает rbx, оказывается в кеше, что позволяет определить исходное значение rax (измеряя время доступа для всех возможных значений коих 256 всего). При этом код не выполняется напрямую (иначе бы упал с AV, хотя TSX позволяет это заглушить), только спекулятивно через OoO engine. Данный код в целом работает и на amd, что кагбе намекае.
Advanced member
Статус: Не в сети Регистрация: 16.05.2010 Откуда: Ленинград Фото: 559
woody писал(а):
через TSX
Речь об амд. Дело в том что в статье я не увидел какую модель они тестировали,список интел там есть. Это странно выглядит от авторов-маленький абзац и всё.
AMD FX(tm)-8320 Eight-Core Processor (called "AMD FX CPU" in the rest of this document) AMD PRO A8-9600 R7, 10 COMPUTE CORES 4C+6G (called "AMD PRO CPU" in the rest of this document) An ARM Cortex A57 core of a Google Nexus 5x phone [6] (called "ARM Cortex A57" in the rest of this document
И ТАМ ССЫЛКА НА ВАШ документ-в котором так и нет амд процов, а эти ребята не проводили тесты на Variant 3: rogue data cache load (CVE-2017-5754) Meltdown (variant 3) и я знаю почему
Other microarchitectures Our research was relatively Haswell-centric so far. It would be interesting to see details e.g. on how the branch prediction of other modern processors works and how well it can be attacked.
Member
Статус: Не в сети Регистрация: 08.02.2009 Откуда: Ульяновск
да вот почитал про падение производительности хоть и в определенных сценариях -и что то нет желания если честно его ставить,хотя в дальнейшем все равно ведь придет.а список изменений в патче я читал -абсолютно ничего для меня нужного
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 29
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения