The slides also seem to confirm that the upcoming Z390 Express chipset doesn't bring any new features

cucker tarlson8c/8t and solder, 4.6GHz all core turbo out of the box, 9700K looks incredibly good.

Intel seems to recommend the Z390 to make the most money for its board partners & licensing fees.

RejZoR6 and 8 core CPU's without HT in 2018. Clock or not, this is incredibly poor. I have a 6 core CPU with 12 threads. Sure, it doesn't clock to 4.x out of the box, but come on, with manual overclocking, I have it at 4.5GHz and 12 freaking threads. TWELVE! The IPC gain is nowhere near as significant as some say it is on newer CPU's, it's basically just gains from higher clocks. 5820K is 4 years old. One would expect things from HEDT to finally trickle down to normies ranges by now. I guess Intel just can't get out of their skin...

9600K should be 6c/12t
9700K should be 8c/16t
9900K should be 10c/20t

With HEDT far beyond that starting at 16c/32t. Sigh.

cucker tarlson8c/8t and solder, 4.6GHz all core turbo out of the box, 9700K looks incredibly good.

Intel*NOT all features available on all SKUs

cucker tarlsonLol who wants HT for gaming if they can get a core count increase.

I get you CPU has TWELVE "friggin threads" :laugh:, but 8600K whips it in gaming so who cares about that.

cucker tarlsonLol who wants HT for gaming if they can get a core count increase.

I get you CPU has TWELVE "friggin threads" :laugh:, but 8600K whips it in gaming so who cares about that.

RejZoR6 and 8 core CPU's without HT in 2018. Clock or not, this is incredibly poor. I have a 6 core CPU with 12 threads. Sure, it doesn't clock to 4.x out of the box, but come on, with manual overclocking, I have it at 4.5GHz and 12 freaking threads. TWELVE! The IPC gain is nowhere near as significant as some say it is on newer CPU's, it's basically just gains from higher clocks. 5820K is 4 years old. One would expect things from HEDT to finally trickle down to normies ranges by now. I guess Intel just can't get out of their skin...

9600K should be 6c/12t
9700K should be 8c/16t
9900K should be 10c/20t

With HEDT far beyond that starting at 16c/32t. Sigh.

Red Hat strongly recommends that customers take corrective actions, including manually enabling specific kernel parameters or potentially disabling features like Intel Hyper-Threading, after the available updates have been applied. More details can be found in the Mitigations section of this article.

Another aspect of the risk in this area goes away if SMT is disabled, so keep it disabled!

noel_fsAh, and of course, after 5 years asking for soldered IHS they bring it, they already have stretched it enough to make nice benefits from filling their cpu's with clay


Another retard, its supposed that these cpu's already come hardware patched for this vulnerability type of thing

R0H1TYou might wanna rethink about that :banghead:
access.redhat.com/security/vulnerabilities/L1TF

marc.info/?l=openbsd-tech&m=153431475429367

The precise impact of L1TF to Hyper-Threading depends upon the specific use case and the virtualization environment being used. In some cases, it may be possible for public cloud vendors (who have often built special purpose hardware to assist in isolation) to take steps to render Hyper-Threading safe. In other cases, such as in a traditional enterprise environment featuring untrusted guest virtual machines, it may be necessary to disable Intel Hyper-Threading.

NokironDisabling HT for end-users is absolutely not needed. It's for cloud-based servers.

I suggest you read on what the reason for it is.


www.redhat.com/en/blog/deeper-look-l1-terminal-fault-aka-foreshadow

R0H1Taccess.redhat.com/security/vulnerabilities/L1TF

marc.info/?l=openbsd-tech&m=153431475429367

randomUserAll vulnerabilities are about virtualization. This means that this only applies to enterprise, who are using these cpu's for their servers.
The gamers and the majority of the consumers of these cpus, will most likely never have such situation, thus vulnerability is meaningless and turning off HT is pointless.

The next vulnerability about the 'code' from one browser tab reaching memory of the other tab may happen at the computers of the majority of these users, but again, i think it was not related to HT at all.
Besides, what stops you from closing the browser, reopening it freshly and then navigating to your bank account. Its not like people have tabs of pron open at the same time as internet bank tabs.

R0H1TDisabling HT will reduce the avenues where such spectre vulnerabilities affect current Intel processors, and no it's not just about VM. IIRC the first reveal earlier this year also suggested disabling HT in extreme cases where security was paramount.

In particular, it is ill-advised to run different security domains (address spaces) on a pair of hyperthread CPUs," he said. "Maybe there are other ways to resolve this problem, but Intel isn't sharing solutions with us. We have selected the expedient approach of disabling hyperthreading until we know more.

However, the general mitigations described in this paper should still be applied as disabling hyperthreading does not in itself provide mitigation for L1TF. Mitigation is also not required in situations where step 2 in the L1TF Limiting Factors section has been entirely mitigated, such as on systems with mitigations in the bare-metal OS that do not run virtual machines.

NokironIt's all about virtualization. If you run on physical hardware only the software patches are the only ones needed.

It was only OpenBSD that decided they preventatively disabled HT.


www.itwire.com/security/83301-openbsd-disables-hyperthreading-support-for-intel-cpus-due-to-likely-data-leaks.html

Intel themselves said that disabling HT is not a mitigation.


software.intel.com/security-software-guidance/insights/deep-dive-intel-analysis-l1-terminal-fault

R0H1TSay that again? SGX isn't about virtualization, you might wanna reread CVE-2018-3615, CVE-2018-3620, CVE-2018-3646.

randomUserIt seems that it is all dependant on a localy run malicious code. Which means you have to download it/ or get infected somehow and run it.

Again, this comes down to virtualization. Data centers are the targets which could be affected.
Malicious code may on purpose be placed in one of the guest machines and access memory of the cpu serving tens of other machines.
You REALLY need to know what to look for in this 32KB cache which is changing very fast.

Usual consumer will most likely not get affected, and i mean if a user downloaded a virus, and that virus get past the anti-virus, then nothing on earth will help protect against data theft. A simple keylogger will do a better job than SGX vulnerability.