Re: Intel Fail: OpenBSD disables Intel HyperThreading, Lazy FP State Restore
Funny watching benchmarks of Intel CPUs plummet 10's of percent... exploit after mitigation after exploit after microcode after... "Intel just took a further shortcut" -- World "Protecting our customers and their data continues to be a critical priority for us." -- Intel
Re: Intel Fail: OpenBSD disables Intel HyperThreading, Lazy FP State Restore
On Mon, Jun 25, 2018 at 05:22:11PM +0300, Georgi Guninski wrote: > On Wed, Jun 20, 2018 at 07:44:21PM -0400, grarpamp wrote: > > https://www.mail-archive.com/source-changes@openbsd.org/msg99141.html > > According to journos intel won't fix this: > https://www.theregister.co.uk/2018/06/22/intel_tlbleed_key_data_leak/ > Meet TLBleed: A crypto-key-leaking CPU attack that Intel reckons we > shouldn't worry about > How to extract 256-bit signing keys with 99.8% success > > Intel has, for now, no plans to specifically address a side-channel > vulnerability in its processors that can be potentially exploited by > malware to extract encryption keys and other sensitive info from > applications. Surely a simple and far less impactful "solution" to this problem is for applications to disable hyperthreading when they enter the critical sections of code - generating (and using?) crypto keys and random numbers for example? OpenBSD is understandable of course - "security or die" - but perhaps they will relax their HT disabling over time as they sure app the HT barrier code required to implement the above…
Re: Intel Fail: OpenBSD disables Intel HyperThreading, Lazy FP State Restore
On Wed, Jun 20, 2018 at 07:44:21PM -0400, grarpamp wrote: > https://www.mail-archive.com/source-changes@openbsd.org/msg99141.html According to journos intel won't fix this: https://www.theregister.co.uk/2018/06/22/intel_tlbleed_key_data_leak/ Meet TLBleed: A crypto-key-leaking CPU attack that Intel reckons we shouldn't worry about How to extract 256-bit signing keys with 99.8% success Intel has, for now, no plans to specifically address a side-channel vulnerability in its processors that can be potentially exploited by malware to extract encryption keys and other sensitive info from applications.
Re: Intel Fail: OpenBSD disables Intel HyperThreading, Lazy FP State Restore
On Wed, Jun 20, 2018 at 07:44:21PM -0400, grarpamp wrote: > https://www.mail-archive.com/source-changes@openbsd.org/msg99141.html > https://www.intel.com/content/www/us/en/security-center/default.html > Freebsd: https://www.freebsd.org/security/advisories/FreeBSD-SA-05:09.htt.asc Topic: information disclosure when using HTT Announced: 2005-05-13 When running on processors supporting Hyper-Threading Technology, it is possible for a malicious thread to monitor the execution of another thread. V. Solution Disable Hyper-Threading Technology on processors that support it.
Intel Fail: OpenBSD disables Intel HyperThreading, Lazy FP State Restore
https://www.mail-archive.com/source-changes@openbsd.org/msg99141.html https://www.intel.com/content/www/us/en/security-center/default.html Mark Kettenis Tue, 19 Jun 2018 12:30:19 -0700 Log message: SMT (Simultanious Multi Threading) implementations typically share TLBs and L1 caches between threads. This can make cache timing attacks a lot easier and we strongly suspect that this will make several spectre-class bugs exploitable. Especially on Intel's SMT implementation which is better known as Hypter-threading. We really should not run different security domains on different processor threads of the same core. Unfortunately changing our scheduler to take this into account is far from trivial. Since many modern machines no longer provide the ability to disable Hyper-threading in the BIOS setup, provide a way to disable the use of additional processor threads in our scheduler. And since we suspect there are serious risks, we disable them by default. This can be controlled through a new hw.smt sysctl. For now this only works on Intel CPUs when running OpenBSD/amd64. But we're planning to extend this feature to CPUs from other vendors and other hardware architectures. Note that SMT doesn't necessarily have a posive effect on performance; it highly depends on the workload. In all likelyhood it will actually slow down most workloads if you have a CPU with more than two cores. ok deraadt@
