-
Competitor rules
Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.
Yet another Intel CPU security vulnerability!
- Thread starter Selekt0r
- Start date
AMD certainly aren't resting on their laurels right now - Intel would be in serious trouble if their 7nm process doesn't live upto scratch with their seeming refusal as a last ditch to outsource production to companies like TSMC and Samsung. By the time their 10nm process is up and running in live products at best they are treading water versus AMD now.
Cry me a river. What non sense.
Just about to move one of my test DB servers and run a few more tests but against the xeon 5690's I was running before the uplift is looking significant.
Haven't seen any complex IO benchmarks yet wondering what that is like - it has traditionally been a weakness versus Intel equivalents.
No idea to be honest I think id bottleneck at the fiber back to the disk infrastructure. I just dunno yet, I mean the thing to do will be run all my jobs and see how long they take, swap the server and see again. If it isn't faster than a 5690 then I should just cry.
The GZip benchmarks (not a perfect indicator) look like they are still slightly trailing Intel Gold so probably still an area they need to work on. Not generally a problem but a consideration if you have say a database server that is getting hammered (depending on what is actually the load point).
I have 9 database servers but can probably offset that with a few more cores than they had previously. I mean Rome should smash a dual socket 5690 in pretty much every metric I would have thought. I shall let you know if I find any workloads where it doesn't.
Yeah I'd be very surprised if it doesn't smash a dual 5690 setup heh. Be interested to know how it compares none the less.
You still dont get it.
There is a big difference between running code through a local command and inside a browser isolated sandbox when you testing security.
They also used local system commands to identify core IDs and lock the two processes to a specific physical core. Being able to determine and run on the same physical core is critical to these type of attack. A proof of concept is exactly that, it is not proof that such a thing exists, is viable, or even complete.
The whole point of the bug is that sandbox's and VM's don't protect you from RIDL because the hardware allows you to bypass them. The while paper states that they were able to complete the attack from spidermonkey. So this is just another attack. You should be banned m8, when will your harassment stop?
Web browsers are capable of running JavaScript outside the sandbox, with the privileges necessary to, for example, create and delete files.
Microsoft Windows allows JavaScript source files on a computer's hard drive to be launched as general-purpose, non-sandboxed programs.
Depends how it's setup, but as its stated in the while paper it does not matter. You know this because you have read the white paper by now. This is a poorly contrived argument.
Despite that a VM running an OS within it or some other secure enclave, a sandboxed exe/application and sandboxed interpreted script are very different situations and RIDL doesn't apply equally across them. Especially different approaches had to be taken to overcome different demands with setting up synchronization and the feedback channel and how much control they have of the local environment which presents different limitations - you can't just pull one bit from the white paper and apply it indiscriminately. You also can't apply success in the white paper indiscriminately - some bits translate into something that is viable in a real environment other bits are only successes in a highly theoretical sense that can never be put into practise as is. The JavaScript example was a "success" but ignoring all other obstacles (which are also relevant in a real browser) in a real environment it would take literal years of snooping, assuming the target did the same thing day after day, to achieve what they did naturally without having ability to control the victim. (Their specially crafted victim process stores the data they want to "steal" 1000s of times over the course of the exploit - in a real environment that happens maybe 2-3 times a day).
Last edited:
Give it a break, the forum admin should ban you. Not that I am tell him to do anything. All your arguments are non sense, I am not playing this game with you. I have a right not to be harassed with your vain attempt to attack me. You have discredited yourself a long time ago.
You could point out where I am wrong (I'm not)... I mean I've given a reasoned response which should be possible to compare against the white paper...
Stop harassing me, I have answered more than a reasonable amount of your questions and gave you a decent debate.
Harassment goes both ways - when people repeatedly insist I'm wrong with no intention of trying to understand what I'm saying even when I explain it, ignore the reasoning in my posts and misconstrue my posts for their own agenda (sadly often fanboy driven) it is pretty insulting really.
You are in the wrong. You really need to start getting it together.
I'm I am wrong then you will have no problem deconstructing the reasoning I've presented in the following posts:
https://forums.overclockers.co.uk/posts/33029220
https://forums.overclockers.co.uk/posts/33029348
https://forums.overclockers.co.uk/posts/33030904
If you are unwilling or unable it would be nice if you did the decent thing and retracted your earlier posts.
I will say again - these exploits are theoretically and academically interesting because it should not be possible for this information to be leaked across these domains even in a highly theoretical concept but to actually work at all there are considerable obstacles, some of which aren't explicitly explained in the white paper but are there all the same - and fairly obvious if you have enough experience working in the relevant field(s). Which means that on your average desktop system they already need one foot in the security door because they not only need to compel whatever process is managing the data they want to steal to constantly store that data in a way that means it is presented over and over in a buffer they can leak information from but also need to have some idea of what that data already looks like so that they can extract it from the noise of other data which is present in these buffers. A feat that in some situations might just about be accomplished in a situation where they have access to the system via services on a server and a wider range of opportunities to invoke processes from unprivileged code and unrealistic against the average consumer desktop.
Last edited:
Admin please lock this thread.