ZoranC
So question is: is Win10 20H2 supposed to have native support for TB3 when that option is enabled in BIOS?

ZoranC

Merilwen
Is this it listed on EVGA's X299 driver downloads?
 
Intel^(R) Turbo Boost Max Driver v1.1.0.1055
https://www.evga.com/supp...art_number=142-SX-E297

 
I'm talking about one that comes with Win10. Win10 installs its own (at least build 1909 did) and you didn't need separate install. Plus Intel based ones had security flaw that made Intel discontinue their own.

Sultan.of.swing
I always disable it in BIOS since i'm overclocking anyway.

arestavo

ZoranC

Sultan.of.swing
I always disable it in BIOS since i'm overclocking anyway.

That works for you because you end up having all cores with same multiplier, correct? But if one has, for whatever reason, overclocked cores to have different multipliers (better ones higher) having Turbo Boost would still result in benefit when executing programs that benefit from favoring cores, correct?

AFAIK, once you manually overclock (per core or all core) that program ceases any useful function. Maybe it will work as a pointer for the stronger cores, but I didn't see that as an option after I add any game/application to the its list (I use Project Lasso for that type of thing, and it's much more robust). Then again, I could be reading it incorrectly.

mikecli

ZoranC
It was my understanding that overclock or no overclock it was supposed to favor faster cores for lightly threaded workloads.

This was also my understanding. I tested this before monitoring HWINFO whilst running single thread benchmarks; ITBM 3.0 would automatically move the workload to the top binned core (no matter the overclock). I was running my 9900X with 2 cores at 5Ghz and the other cores at 4.8Ghz and it seemed to be doing it's thing just fine.

mikecli
I tested this out; Switched the BIOS setting over to "Native OS support" instead of "MFC Override". However when I ran a single thread BM, the core load would jump around all over the place --essentially it doesn't seem like the OS supports this function.

mikecli
I mean, I'm willing to just reinstall the app if this vulnerability is one of those really obscure ones where you need to run a virus and then have the moons aligned so the hacker can read machine code in a 10 second window, type of thing.

mikecli
Either way, it's really ****ty because IBMT 3.0 was a key selling point in their marketing of the HEDT platform.

mikecli
Edit: I'm hoping it's ii) and that we can badger Microsoft for a fix or perhaps there is some setting we haven't discovered to enable this natively in the OS. The cynic in me can forsee Microsoft passing the parcel back to Intel and so forth.

mikecli
I'm going to find this one hard to drop, mainly because i got the short end of the silicon lottery stick with my 9900X; my cores have quite a variation in quality and I can't get a cache overclock higher than 29 (My previous 7820x, Rip, could handle 32) so I feel like I need to compensate by squeezing as much juice as possible.
 
I also really like the concept of having better cores that you can optimise for faster low threaded tasks. Intel is kind of moving in this direction anyway with its Arm-like big.little cores implementation for next gen.
 
I'm going to persist and try find a solution. Failing that I'm probably just going to YOLO run the driver.

safan80

mikecli
I'm going to find this one hard to drop, mainly because i got the short end of the silicon lottery stick with my 9900X; my cores have quite a variation in quality and I can't get a cache overclock higher than 29 (My previous 7820x, Rip, could handle 32) so I feel like I need to compensate by squeezing as much juice as possible.

I also really like the concept of having better cores that you can optimise for faster low threaded tasks. Intel is kind of moving in this direction anyway with its Arm-like big.little cores implementation for next gen.

I'm going to persist and try find a solution. Failing that I'm probably just going to YOLO run the driver.

The risk is lower than you might think. Unless someone has physical access to the machine.

mikecli
  
Digging a little deeper, this seems to be related or somewhat similar to the Spectre/Meltdown exploits, it was also uncovered around the same time. My theory is that Intel effectively pushed responsibility onto Microsoft after the exploit was published, either because i) they're lazy or ii) to function properly without an exploitable vector it has to be built into the OS and MS just doesn't care or iii) they know the concept is fundamentally flawed in that it cannot be fixed without it being exploitable. 

A good firewall setup including port blocking and in some cases IP blocking like fishy Asia based IPs (you can look up some trouble some IPs on the internet) and in terms of a solutions just run a known good anti virus product (I won't name names because that will start a fame war) and the progrtam will monitor the risk. If you are not in the habit of downlload strange attachments in emails or fishy programs off the net you will not have the problem. My broadwell-E based workstation had the same problem, but it was 10% performance that really wasn't going to affect me, so I ran the older bios until I sold the setup and I solld it with the updated bios installed. I do want that driver though. MSFT will not fix it because their fix was to remove the driver.

mikecli
OK so the plot thickens. I started messing around switching between "MFC Driver Override" and "OS Native Support" to do some benchmarking. Despite the apparent discontinuation, Windows 10 auto-installs the Intel driver under "MFC Driver Override" and the Intel Turbo Boost Max 3.0 application was also present in the system tray. Strange given there was a public notice issued about the potential exploit, yet they are automatically installing drivers and apps under the default Windows install.. Anyway, I switched back to OS Native, then checked threads under load and to my surprise the thread prioritising function seemed to be working natively! I double checked: driver missing from Device Manager, ok that looks right, and also no ITBMT app in the tray. I don't know whether it was because I didn't look properly before or somehow installing the driver and then switching back to "OS Native Support" did something, but it worked, at least in that a 2 threaded load was prioritised on my 2 best cores. I also observed the following:
 
- Under "OS Native", the boost only works for 2 threads maximum, whereas under "MFC Driver Override" with the driver, the cores were prioritised in order of "preference"; i.e. best core first followed by next best and then so on. This was apparent if you put a 4 thread prime95 load on; under OS Native it only prioritised the first 2 threads and the other two were just placed in order of core #number.
 
- Benchmark scores in CPUID and Cinebench were always better under "MFC Driver Override" by about 2-3% in single thread.
 
- CPUID has a "stress CPU" function which seems to confuse the boost setting for both "Native" and "Override" past 2 threads.
 
 
I also noticed that Intel's advisory states:
"Description: Improper permissions in the installer for Intel(R) Turbo Boost Max Technology 3.0 driver version 1.0.0.1035 and before may allow an authenticated user to potentially enable escalation of privilege via local access."
There was an ITBMT 3.0 driver offered by Asus my motherboard maker, version 1.1.0.1005, which is newer and was released 2-3 months before the advisory in 2019. Does it mean that this driver is safe to use? (I didn't notice which version Windows installed by default, I should have made a note beforehand).

safan80
That bulletin states Local access meaning someone with a local account on the machine, so really the risk is low I.E. don't use on a machine with critical info. You can easily tell via task manger under the details which local users are logged in.

ZoranC
 
 
Is risk lower than in corporate environment? Maybe. But that doesn't mean it is low or non-existent. Is few percent in performance worth that risk? Not to me.

ZoranC

safan80
That bulletin states Local access meaning someone with a local account on the machine, so really the risk is low I.E. don't use on a machine with critical info. You can easily tell via task manger under the details which local users are logged in.

Please notice they say -authenticated- user which is not same as regular user nor same as user currently logged in. IMHO phrasing of such advisories is usually such that can be misleading. Usually they say "authenticated local user" when more accurate would be "ANY account that will get successfully authenticated locally, whether it be one of accounts for people or one of system accounts  that will be successfully authenticated on that machine".
 
Attacker can use -ANY- compromised account to escalate his privileges and Task Manager will -NOT- show you that.

ZoranC
 
 
Which build of Windows you are on, 20H2 or earlier?
 
It is hard for me to guess what might be going on in your case as I don't know details of your test and you have different mb. I also use MSDN install media for Pro for Workstations and I haven't tried to see what happens if I use different/consumer install media.
 
However, when I searched what might be happening with mine I came across posts that indicated Intel's driver shouldn't be used with Asus mb, that Asus one is better. Does that mean Asus doesn't have same vulnerability? Which one is better, Asus or Microsoft's native? Only Asus and Microsoft would know that.