Ты значение слова "в среднем" знаешь? Так вот, чтобы "в среднем" было 5-10%, в случае если половина тестов вообще не показывает разницы, тесты в которых есть разница должны показывать 10-20%. Чего не происходит. Половина тестов вообще индифферентна, в худших случаях синтетики - до 10%.

Третий вид пока что воспроизведен только под Интел и ARM. Но не факт, что так или иначе, данная уязвимость не сможет быть позже воспроизведена под АМД.

1)стим клиент лиц соглашение о сборе данных

1000акков, одного человека не повлияет, в 1000 человек да

а где кнопка на стиме для опроса компьютера?

вообще-то никто и не кричал об неуязвимости, тут о другой ошибки ведем речь

Как сообщают специалисты, уязвимости Meltdown подвержены все процессоры Intel с поддержкой исполнения команд с изменением последовательности (out-of-order execution). Это почти все чипы, выпущенные с 1995 года за исключением серии Itanium целиком и чипов Atom до 2013 года. В настоящее время нет подтверждений о том, что процессоры ARM и AMD подвержены Meltdown.

Это не кнопка, а окно, которое может появиться после залогинивания, в первом окне задаётся вопрос "хочешь поучаствовать в опросе железа?", если хочешь - последовательно появляются окна с вопросами о наличии микрофона, о скорости интернета и т.д., после этого твои данные должны добавиться в статистику.

Любое исследование в подтверждение, что залогинивание с нескольких аккаунтов на одном и том же компе меняет статистику?
Иначе это просто предположение.

Процитируй пункт.

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

Речь шла про тяжелые серверные нагрузки: БД и VM. Там эти 5-10% в среднем и есть. Там где падения производительности нет нагрузки либо никакие, либо программа написана так что работает только в userspace и минимально дергает ядро ОС.

Ты программист? Объяснишь как? Ибо я понимаю что никак, поскольку аппаратно осуществлен контроль доступа через флаги. У Intel такого нет by design...
Вот есть табличка: https://www.amd.com/en/corporate/speculative-execution
В ней пока ничего не поменялось.

Variant 3: Rogue data cache load
Basically, read Anders Fogh's blogpost: https://cyber.wtf/2017/07/28/negative-r ... user-mode/

In summary, an attack using this variant of the issue attempts to read kernel memory from userspace without misdirecting the control flow of kernel code. This works by using the code pattern that was used for the previous variants, but in userspace. The underlying idea is that the permission check for accessing an address might not be on the critical path for reading data from memory to a register, where the permission check could have significant performance impact. Instead, the memory read could make the result of the read available to following instructions immediately and only perform the permission check asynchronously, setting a flag in the reorder buffer that causes an exception to be raised if the permission check fails.

We do have a few additions to make to Anders Fogh's blogpost:

"Imagine the following instruction executed in usermode
mov rax,[somekernelmodeaddress]
It will cause an interrupt when retired, [...]"

It is also possible to already execute that instruction behind a high-latency mispredicted branch to avoid taking a page fault. This might also widen the speculation window by increasing the delay between the read from a kernel address and delivery of the associated exception.

"First, I call a syscall that touches this memory. Second, I use the prefetcht0 instruction to improve my odds of having the address loaded in L1."

When we used prefetch instructions after doing a syscall, the attack stopped working for us, and we have no clue why. Perhaps the CPU somehow stores whether access was denied on the last access and prevents the attack from working if that is the case?

"Fortunately I did not get a slow read suggesting that Intel null’s the result when the access is not allowed."

That (read from kernel address returns all-zeroes) seems to happen for memory that is not sufficiently cached but for which pagetable entries are present, at least after repeated read attempts. For unmapped memory, the kernel address read does not return a result at all.

Nimrael вы инженер? или программист?

Вообщем, даже Мельтдаун, скорее всего, при определенных изменениях коснется и АМД. раз уж коснулся и ARM Кортексов в массе (57, 15, 72, 73, 75) и их деривативов (скорее всего Эппл устройства тоже).

Intel is badly hit by Meltdown because its speculative execution methods are fairly aggressive. Specifically, Intel CPUs are allowed to access kernel memory when performing speculative execution, even when the application in question is running in user memory space. The CPU does check to see if an invalid memory access occurs, but it performs the check after speculative execution, not before. Architecturally, these invalid branches never execute — they’re blocked — but it’s possible to read data from affected cache blocks even so.

А вот в бенчах, гонящих синтетику и обладающих непомерным количеством запросов к ОС, просадки могут быть намного больше - до 20% на старых архитектурах.

Именно по мельтдауну (rogue cache load)

Вот описание того почему на Intel и частично на ARM возможно:
Intel is badly hit by Meltdown because its speculative execution methods are fairly aggressive. Specifically, Intel CPUs are allowed to access kernel memory when performing speculative execution, even when the application in question is running in user memory space. The CPU does check to see if an invalid memory access occurs, but it performs the check after speculative execution, not before. Architecturally, these invalid branches never execute — they’re blocked — but it’s possible to read data from affected cache blocks even so.

На AMD проверка прав происходит до исполнения команд в отличие от Intel и это by design уязвимость. Какая тут еще нахрен "при определенных изменениях"? Изменениях в дизайне процессора?

A short summary of what this security bug means:

Code utilizing this exploit works on Windows, Linux, etc., as this is not a software- but a hardware issue.
It is possible to dump arbitrary kernel memory with unprivileged user space applications.
Reading kernel memory implies reading the memory of the whole system on most 64 bit operating systems, i.e. also memory from address spaces of other processes.
Fully virtualized machines are not affected (guest user space can still read from guest kernel space, but not from host kernel space).
Paravirtualized machines are affected (e.g. Xen PV).
Container solutions like Docker, LXC, OpenVZ are all equally affected.
The Linux KPTI / KAISER patches mitigate Meltdown effects on Linux.
Most modern processors, in particular with Intel microarchitecture since 2010, are affected.
We have no evidence that this attack is successfully deployable on ARM or AMD, although the underlying principle applies to all contemporary superscalar CPUs.
Meltdown is distinct from the Spectre attacks, which became public at the same time.

Я опираюсь на слова тех, кто собственно и исследовали уязвимости.

We have no evidence that this attack is successfully deployable on ARM or AMD, although the underlying principle applies to all contemporary superscalar CPUs.

Табличку AMD смотри, опирается он.

Там провели внутренние тесты да и проводить их в принципе (что касается конкретно Melydown) не нужно, так как out of order execution на AMD работает немного по другому, что сама AMD прекрасно знает! Ты лучше приведи доводы, которые говорят хоть как-то в пользу возможности проведения подобной атаки. Пока нет тестов, опровергающих слова AMD все остальное чисто фантазии, особенно без каких либо доводов.

надежда на то, что интел на 30% просядет в играх и рузены догонят - не подтверждается



#77


ну и так далее там их много
наоборот, видно кое-где даже небольшой прирост

ну, посмотрим чо будет на винде

да тоже самое будет скорее всего

АМД уже громко кричали вчера, что их и Спектр не касается.

И в табличке та же глупость указана по второй атаке.

Differences in AMD architecture mean there is a near zero risk of exploitation of this variant. Vulnerability to Variant 2 has not been demonstrated on AMD processors to date.

Resolved by software / OS updates to be made available by system vendors and manufacturers. Negligible performance impact expected.

АМД уже громко кричали вчера, что их и Спектр не касается.

Согласно ему атака на AMD никогда не пройдет, ибо будет произведена проверка привилегий перед исполнением инструкций и ты будешь послан...

Даже гугл признался, что уязвимости подвержены все процы, включая AMD:

Google: Vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel
http://www.guru3d.com/news-story/google ... intel.html

Вы не верите гуглу?

ничё что это тесты гпу а не цпу?

А мелкие операции с диском (а с сетью они вообще всегда мелкие

установи стим клиент и посмотрим кто кого спросит

или ты теоретик?

ты же в курсах о пункте конфиденциальности.
откр лиц, персональные данные

Откуда вам известно какие задачи я запускаю на Пк))

Вот ссылка на оригинал - найди там про AMD и meltdown.