Intel processor design flaw requiring ROS kernel mode change

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

dizt3mp3r
Posts: 1447
Joined: Mon Jun 14, 2010 5:54 pm

Re: Intel processor design flaw requiring ROS kernel mode ch

Post by dizt3mp3r » Fri Jan 05, 2018 5:10 pm

We're all fecked. At the moment I can't even get my win7 64 system to start installing those powershell modules without installing a load of Microsoft of Microsoft bloat. How difficult is this going to be for the ordinary man in the street?

The patch wasn't even made available to my Win7 64 system, I had to upgrade Avast and malwarebytes, add the registry entry manually as was there but the value still hadn't changed. Even then the update would not trigger. In the end I manually downloaded the correct patch and installed it myself. Many won't be able to do what is required as they have come to expect seamless operation.

I have an Apple iphone 4 (solid and working well) three older ipads for my kiddies - all running older versions of IOS and none of them will receive a patch from Apple, they are all the equivalent of bricks now as we cannot use them to access any site that has a password. Even so they will all be acting as trojan access points to my network and I have to tell my kid's mother that they have to stop using them forever. Thanks Apple for your policy of not-updating old versions of IOS. I have to pull the passwords from my iphone as well or never use it for browsing the web, never install any new software...

As I said, we're all fecked by it. I'm never buying Apple again.

zydon
Posts: 160
Joined: Tue Dec 18, 2007 9:03 am

Re: Intel processor design flaw requiring ROS kernel mode ch

Post by zydon » Sat Jan 06, 2018 7:53 am

I think there is still a solution to protect your data by banking them into Bay Trail and Cherry Trail devices (laptops, phones, compute stick and tablets). Those Intel Atom PCs are selling cheap now for the stock clearance in a month or two.

I wish ReactOS would boot on these Intel Atom tablet in the near future. I hope it sooner than later.... ;)

dizt3mp3r
Posts: 1447
Joined: Mon Jun 14, 2010 5:54 pm

Re: Intel processor design flaw requiring ROS kernel mode ch

Post by dizt3mp3r » Sun Jan 07, 2018 2:40 pm

zydon wrote:I think there is still a solution to protect your data by banking them into Bay Trail and Cherry Trail devices (laptops, phones, compute stick and tablets). Those Intel Atom PCs are selling cheap now for the stock clearance in a month or two.

I wish ReactOS would boot on these Intel Atom tablet in the near future. I hope it sooner than later.... ;)
or Itanium...

milon
Posts: 969
Joined: Sat Sep 05, 2009 9:26 pm

Re: Intel processor design flaw requiring ROS kernel mode ch

Post by milon » Sun Jan 07, 2018 4:18 pm

Bummer. I was really hoping that my core2duo was old enough to avoid this, but nope. What's this about Bay Trail and Cherry Trail? And I've got an old Atom processor system. Are they unaffected?

dizt3mp3r wrote:PS. You need to check your use of slang "sh1tt1ng" is not an appropriate word for a technical forum - you should really avoid any use of such slang that is considered an expletive in some cultures. In the UK that is still a swear word even if the Americans use it hourly in normal speech. It sounds bad to our ears and in our minds when we have to read it. It is also wrong to use it here as it adds nothing to the technical discussion. Simply put - avoid all slang.
dizt3mp3r wrote:We're all fecked...
As I said, we're all fecked by it...
kek :)

dizt3mp3r
Posts: 1447
Joined: Mon Jun 14, 2010 5:54 pm

Re: Intel processor design flaw requiring ROS kernel mode ch

Post by dizt3mp3r » Sun Jan 07, 2018 7:08 pm

From what I have read it seems that all Intel CPUs from 2007 onward have vulnerabilities to Spectre-type exploits, thataccording to some even includes those core2duo systems that were prevalent at that time. This has been stated officially and a quick look at the list of Intel's affected cpus tells us exactly what was created from 10 years ago - and that's up to and including the most recent i3/5/7 processors.

Here's the complete list, as published by Intel.*2

Intel Core i3 processor (45nm and 32nm)
Intel Core i5 processor (45nm and 32nm)
Intel Core i7 processor (45nm and 32nm)
Intel Core M processor family (45nm and 32nm)
2nd generation Intel Core processors
3rd generation Intel Core processors
4th generation Intel Core processors
5th generation Intel Core processors
6th generation Intel Core processors
7th generation Intel Core processors
8th generation Intel Core processors
Intel Core X-series Processor Family for Intel X99 platforms
Intel Core X-series Processor Family for Intel X299 platforms
Intel Xeon processor 3400 series
Intel Xeon processor 3600 series
Intel Xeon processor 5500 series
Intel Xeon processor 5600 series
Intel Xeon processor 6500 series
Intel Xeon processor 7500 series
Intel Xeon Processor E3 Family
Intel Xeon Processor E3 v2 Family
Intel Xeon Processor E3 v3 Family
Intel Xeon Processor E3 v4 Family
Intel Xeon Processor E3 v5 Family
Intel Xeon Processor E3 v6 Family
Intel Xeon Processor E5 Family
Intel Xeon Processor E5 v2 Family
Intel Xeon Processor E5 v3 Family
Intel Xeon Processor E5 v4 Family
Intel Xeon Processor E7 Family
Intel Xeon Processor E7 v2 Family
Intel Xeon Processor E7 v3 Family
Intel Xeon Processor E7 v4 Family
Intel Xeon Processor Scalable Family
Intel Xeon Phi Processor 3200, 5200, 7200 Series
Intel Atom Processor C Series
Intel Atom Processor E Series
Intel Atom Processor A Series
Intel Atom Processor x3 Series
Intel Atom Processor Z Series
Intel Celeron Processor J Series
Intel Celeron Processor N Series
Intel Pentium Processor J Series
Intel Pentium Processor N Series

Regardless of what Intel officially states the list is far more extensive than this *2.

*2 - This list from Intel implies core2duo are not included but checking some of the older technical specification documents reveals references to speculative execution so we must assume that the older processors are affected too.

PS sorry about the feck.

DGMurdockIII
Posts: 123
Joined: Sat Sep 16, 2006 8:30 pm

Re: Intel processor design flaw requiring ROS kernel mode ch

Post by DGMurdockIII » Sun Jan 21, 2018 9:57 pm

https://meltdownattack.com/ lots of info and link to official patches

zydon
Posts: 160
Joined: Tue Dec 18, 2007 9:03 am

Re: Intel processor design flaw requiring ROS kernel mode ch

Post by zydon » Mon Jan 22, 2018 8:07 pm

AMD and Intel Prediction feature never been stable from the beginning. The only processor that solidly stable with Prediction feature is Cyrix. I heard the last Cyrix CPU tech was owned by VIA, Would VIA chip could stand Meltdown and Spextre attack?

Anyone had HP netbook with VIA processor probably could tell us the result using the test script.

gabrielmorrow
Posts: 3
Joined: Tue Jun 30, 2015 3:47 am

Re: Intel processor design flaw requiring ROS kernel mode ch

Post by gabrielmorrow » Sun Jan 28, 2018 2:05 pm

dizt3mp3r wrote:Yes I should have mentioned Alex being quoted there, I was too keen to get the news out.

From what I have read it seems that all Intel CPUs from 2007 onward have this vulnerability, that includes core2duo systems that were prevalent at that time. This is not stated anywhere yet but a look at the list of Intel cpus tells us what was created 10 years ago and that's all the core2duo and all the i3/5/7s &c.

The implication is that all Windows o/s need to be patched, XP, Vista, 7 - 8 and 10. I can't see MS avoiding patching 7, 8 or 10 and by implication XP too as it is used in business everywhere and last time there was such a serious flaw XP was patched.

I bet all the AMD users are sitting pretty at the moment. Shows us why we need competition in the CPU market. My two Win10 systems are both AMD. My Win7 system is core 2duo.
patching xp wont happen the amount of changes needed are to great to the kernal from such an outdated os plus that os marketshare is plunging so its not as big an issue

dizt3mp3r
Posts: 1447
Joined: Mon Jun 14, 2010 5:54 pm

Re: Intel processor design flaw requiring ROS kernel mode ch

Post by dizt3mp3r » Mon Jan 29, 2018 8:26 pm

gabrielmorrow wrote:plus that os marketshare is plunging so its not as big an issue
Maybe not for you...but a serious problem for many nevertheless.

P.S. Please turn on your grammer chekkah.

BurchSung
Posts: 1
Joined: Wed Jun 06, 2018 6:45 pm

Re: Intel processor design flaw requiring ROS kernel mode ch

Post by BurchSung » Wed Jun 06, 2018 6:53 pm

Hi...i am a new user here. As per my knowledge the vulnerability only results in a segfault because AMD does actual security checking, Intel chips do no security checking for their instruction prediction and thus are actually vulnerable to arbitrary memory reads.

http://percentagescalculator.com/
Last edited by BurchSung on Tue Jul 03, 2018 10:10 pm, edited 1 time in total.

Ancient
Posts: 81
Joined: Tue Mar 27, 2018 11:32 pm

Re: Intel processor design flaw requiring ROS kernel mode ch

Post by Ancient » Fri Jun 08, 2018 7:14 pm

It appears this is a side affect of a single CPU core sharing 2 hyperthreads. The L1 cache unique to a CPU core isn't isolated to each logical core. Software running in the same core can see L1 prediction information from another process working on the other thread on the same core. Turning hyperthreadding off would work, clearing partial execution data by marking it corrupt on a core when a 2nd thread is started would also solve this. The loss is of prefetch, partial execution, and branch prediction will hurt performance. It is an issue with the dual core design by Intel. The implementation by AMD provides by default isolation between the 2 threads on a single core and L1 cache. Some virtual register access is shared on AMD dual core systems, but can be fixed by microcode modification using their RISC security system to mark the virtual registers as corrupt prior to giving control to another thread on the same core. This is resolved in the AMD BIOS as the RISC security systems via BIOS modification used by modern AMD / Intel systems. ReactOS does not have access to these RISC security systems and can't implement the BIOS fix.

Considering all the issues with ReactOS development, this isn't really in need of a solution. Intel and AMD will solve this in future hardware.

Honestly, USB boot would be a lot more helpful than worrying about this CPU hardware issue. DVD / CD boot devices are less and less common, the inability to boot via USB device is affecting easy testing of ReactOS. Support for proprietary NTFS write capability seems a waste, if ReactOS becomes popular Microsoft will just modify NTFS via a patch and cause ReacOS to damage their improved file system. Read NTFS, yes, write NTFS NO, don't do it. Help users migrate to an alternate FS. ReactOS would be better off keeping focus on FAT for flash boot and small drives, and Linux file systems in lieu of NTFS. Anybody who is going to run ReactOS will want to test boot. They won't want ReactOS damaging NTFS files. If ReactOS damages an existing Windows install, a user will never trust it again. NTFS write is a pain in the tail, taking valuable development resources, and ultimately will easily be an Achilles heel for ReactOS if Microsoft notices market share issues.

USB boot, and 64 bit support are great limiters of ReactOS, in addition to other critical issues. At this time many users will have a multi core processor and easily 8 to 32 GB of RAM mostly with SSD or very large TB hard drives. USB C comes, and USB 2 is still a problem with ReactOS. Getting USB 2 and 3 support after most users migrate to USB C won't help ReactOS. USB support is important now, if delayed ReactOS will be pondering USB C for the next decade or so. Without a CD attached to a HDD controller most users won't test. Installing a VM is how many here are comfortable testing ReactOS, booting off a USB flash drive is how many inexperienced users will eventually be exposed to ReactOS. Already USB C is increasingly in use, support for USB 1,2,3 and C is imperative for ReactOS. C not today, but in the next year or to, absolutely. That we can't boot off USB 2 or 3 devices is not good.

ReactOS needs to be stable on most non-virtual systems, needs USB / PnP / USB Boot support. ReactOS can't be adopted by many users without good support for multi TB drives / SSD drives, my suggestion is these larger / newer drives work with Linux file systems, same even for boot USB drives. Without booting onto non-virtual systems ReactOS will fail, most users will want to boot it on their laptop or PC. ReactOS needs 64 bit RAM support. If it's 64 bit real memory support for real RAM managing a 32 bit paging system ReactOS will be fine.

32 bit virtual memory support won't be an issue for 99% of users. But the memory manager has to be able to access all RAM and manage paging to and from all of memory, virtual storage presented to end users and most user features can be 32 bit for a long time, users won't notice as much. They will notice if 4, 12, or 24 GB of RAM aren't being used. Even though in truth that RAM isn't often necessary for most users. Failure to recognize it will upset users who paid for it. Future CPU's require support for many processing units 64 to 256 hyperthreaded cores, and are in our near future. ReactOS may want to develop an affinity for AMD Ryzen in the short term. The new AMD 64 effective core Threadripper is around the corner, has it been tested?

I would love to boot a ReactOS flash image, or better have a flash image burner which runs under Windows 10 automatically install it on a flash drive. ReactOS MUST boot native off a USB stick or it won't be evaluated by many, it MUST support more than 4 GB of RAM or it will be ignored by most.

Attention to USB support, USB boot, NTFS read, FAT and Linux file system support and 64 bit real memory management while using a 32 bit API and 32 bit page system would likely work well for ReactOS adoption. This would get ReactOS more exposure. Alternatives to Windows will appeal to corporations, but they can easily choose Linux, home users will want ReactOS to run their most popular applications. What are the most popular 100 to 500 applications run on Windows? What are the most popular 10 to 100 most popular games? For example, if ReactOS can't run a popular game, it will fail. Increasingly games are integrated with a market, Microsoft will lock ReactOS out of it's store. Steam has a common launch platform as does Blizzard. Steam, Sony, Blizzard and anyone else popular outside the Microsoft universe should be priorities for gamer's to adapt. Gamer's are a smaller community, but are also influential. Launch ReactOS off a USB drive, then launch Blizzard or Steam and run let users install their games, and you'll have an influential community take interest. Expect some influential users to "test" ReactOS with 64, 128, 256 GB or larger flash drives. This will require flash boot support for a Linux file system.

Eventually a variant of Windows 10 S will be free, and will lock users to the Microsoft store. This is good for ReactOS, IF it can deliver Steam, Sony, Blizzard and other support without the Microsoft store as gatekeeper. However there will be a time in the near future when a crippled Windows 10 64 bit system locked to the Windows store and Windows email accounts will exist. ReactOS can only compete with Windows free if it can show lack of tracking, security, stability, ability to use modern hardware, and ability to load software via traditional methods. ReactOS also needs a unique non-tracking browser. One which can help protect user privacy and still be open source. Google, Bing, and Yahoo search must be avoided. These search engines increasingly direct users to less than 100 websites 99% of the time. Often their own, or other large corporate websites. Not certain, but ReactOS should look for an open source browser which is secure and protects privacy and a search engine which isn't a giant corporation mining data 24/7. These will appeal to users.

The above is my opinion.

ThFabba
Developer
Posts: 263
Joined: Sun Jul 11, 2010 11:39 am

Re: Intel processor design flaw requiring ROS kernel mode ch

Post by ThFabba » Fri Jun 08, 2018 7:40 pm

I don't see why these side channel attacks would be specific to an L1 cache. L2 or L3 should do the trick just as well (or in fact better, since they're shared). User mode also can control which processor(s) its threads run on, so even CPU-specific vs shared cache really shouldn't matter.
ROS should... eventually... probably still implement kernel page table isolation at least. The other mitigations may lose relevance over time, although it seems likely that some of them will still be needed over time, as the processor vendors aren't completely "fixing" current processors.

USB boot is a topic for another thread...

Ancient
Posts: 81
Joined: Tue Mar 27, 2018 11:32 pm

Re: Intel processor design flaw requiring ROS kernel mode ch

Post by Ancient » Fri Jun 08, 2018 9:17 pm

L1 is specific to a core, L2 and L3 are not. The prefetch, virtual registers, and branch prediction are not isolated by thread within core in L1, but are at least somewhat isolated in L2 and L3. L2 and L3 test most security and access between cores and are slower. The dual core concept was to allow a single core to not spend most of it's life idle, L1 and branch prediction / prefetch, partial execution are all necessary to make this work. The core and hyperthread capability is integral to L1, not L2 and L3 which are cross core.

Regardless, the solution will be Ryzen 2 next spring (the real 2, not the 1 update) for AMD, and whatever future processors Intel dreams up to solve this. Legacy support is great for ReactOS, not solving known hardware issues, is a problem for AMD, Intel and BIOS makers, it isn't a problem for ReactOS.

As to USB, sorry, it is relevant. This discussion is about diverting development resources from a great operating system and concept which will derail other needed improvements.

If focus isn't placed on open source file systems supported by Linux, and USB boot, ReactOS will limp along, but isn't likely to thrive. Support for more than NTFS read seems like a good thing, but Microsoft controls NTFS, and can change it at will. Same with the Microsoft store.

Does the steam platform work on ReactOS? How about the Activision Blizzard? Without these working, and very common programs like Chrome or FireFox, 7 zip or WINRaR, Libre Office, so many others, ReactOS will be left without anything useful to do for a user unless popular software works well and is easily installed. 99% of users are going to try and install an anti-virus. How is this addressed? What will Avast or any other AV do with ReactOS? How will this be explained to users? Windows users are trained to feel a need for a "good" anti virus, and will likely drop a platform that doesn't have one. Broad adoption of ReactOS has to at least consider how to respond to a user about this.

No common end user runs Windows 10 for NTFS, most have no clue what it is. Most will want a browser. Steam has 125 million active accounts. Does Steam work on ReactOS? Activision Blizzard has 40 million active Overwatch players. How many installs are there of ReactOS? The Microsoft store and free but crippled Windows 10 S with tons of spying are around the corner. If mom can't Facebook, if dad can't play his videos, if a kid can't play games, ReactOS won't even be considered. Spending resources limiting Facebook and Google browser tabs in a super isolated virtual space so cross tracking could be limited would be nicer than trying to develop workarounds of this hardware bug. And that isn't even worth diverting scarce resources on. Adopters will donate if the product is good enough and seems to offer some advantage over Windows. The trick is to get a few hundred million users, after that it'll be easy. :)

ThFabba
Developer
Posts: 263
Joined: Sun Jul 11, 2010 11:39 am

Re: Intel processor design flaw requiring ROS kernel mode ch

Post by ThFabba » Fri Jun 08, 2018 9:39 pm

Ancient wrote:L1 is specific to a core, L2 and L3 are not. The prefetch, virtual registers, and branch prediction are not isolated by thread within core in L1, but are at least somewhat isolated in L2 and L3. L2 and L3 test most security and access between cores and are slower. The dual core concept was to allow a single core to not spend most of it's life idle, L1 and branch prediction / prefetch, partial execution are all necessary to make this work. The core and hyperthread capability is integral to L1, not L2 and L3 which are cross core.
Hyperthreading and speculative execution are only marginally related to one another. None of this seems to have any relevance to the speculative execution side-channel attacks that this thread is about.
Ancient wrote: Regardless, the solution will be Ryzen 2 next spring (the real 2, not the 1 update) for AMD, and whatever future processors Intel dreams up to solve this. Legacy support is great for ReactOS, not solving known hardware issues, is a problem for AMD, Intel and BIOS makers, it isn't a problem for ReactOS.
It's just as relevant to ReactOS as it is to any other OS. Since other OSes have mitigations in place, there's little pressure on the CPU manufacturers to fix all of these issues in current processors (and I think it's been argued that it's impossible?). So unless in the future there will be a CPU-side fix for every one of these issues, for every CPU, the problem will remain relevant to ROS, and we'll eventually need to fix it -- because leaving users vulnerable to attack is not an option.
Ancient wrote: As to USB, sorry, it is relevant. This discussion is about diverting development resources from a great operating system and concept which will derail other needed improvements.
It's not relevant to this thread, which is about this year's speculative execution side-channel attacks.
Nobody is "diverting resources". ReactOS has no management, every individual works on what they choose to work on. If the kernel changes needed to mitigate these CPU bugs are of particular interest to someone, then that person may choose to work on them. If not, then nobody will. The same applies to USB boot as well as every single other area of the OS.

anthracen
Posts: 43
Joined: Thu May 10, 2018 2:28 pm

Re: Intel processor design flaw requiring ROS kernel mode ch

Post by anthracen » Sat Jun 09, 2018 12:10 am

Support for proprietary NTFS write capability seems a waste, if ReactOS becomes popular Microsoft will just modify NTFS via a patch and cause ReacOS to damage their improved file system. Read NTFS, yes, write NTFS NO, don't do it.
...
If focus isn't placed on open source file systems supported by Linux, and USB boot, ReactOS will limp along, but isn't likely to thrive. Support for more than NTFS read seems like a good thing, but Microsoft controls NTFS, and can change it at will. Same with the Microsoft store.
First Microsoft buys github for some billions of dollars to "steal" the ReactOS code and now we get to know, that Microsoft is about to invent a time machine, return in the past and "at will" - change existing NTFS versions. Is it a week of humor over here? Honestly I just cannot understand, what one needs to smoke to write as the above seriously? If MS is going to change NTFS, and it might, but of course NOT for breaking the ReactOS victorious march, - for improvement maybe? so if it is going to do so, it will affect only the future versions. Every previous ones won't be affected. Cannot be. Because there are many hundred of millions of NTFS volumes on this planet in heavy use, formatted as current NTFS. And this is something that cannot get changed "by the patch". And Microsoft cares that all those keep working, it's not apple, easily screwing up their users by entirely dropping support/caring about compatibility etc of previous iThingies (PPC machines are an example) after all, and so, it knows what's backward compatibility means, so even new versions might have been used by the old code even Microsoft's one. do you really think seriously it will patch every existing Windows starting from (NT 3.1) with "different" NTFS and then secretely reformat every of those many of hundreds of millions of NTFS volumes on the Earth just to upset ReactOS? Well well well. :shock:

Post Reply

Who is online

Users browsing this forum: Bing [Bot], Semrush [Bot] and 3 guests