SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 16 submissions in the queue.
SoylentNews
Announced shortly after the 1 year anniversary of the first revelations by Eric Snowden that American spy agencies have their fingers in everything, the Russian government will be funding a project to build a custom microprocessor. Codenamed Baikal (after the lake with Earth's largest volume of fresh water), it will be built around an ARM Cortex A57, a 64-bit architecture running at 2GHz. No core count or other details are available. First deliveries are expected in 2015.
The ARM architecture aligns with Vladimir Putin's goal, announced in 2010, to move all government computers onto Linux. It also comes in the wake of another large country's recent barring of some American technology in favor of a homegrown Linux distro.
This discussion has been archived.
No new comments can be posted.
Russia Plans to Dump Some American CPUs for Homegrown Technology
|
Log In/Create an Account
| Top
| 33 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Life is to you a dashing and bold adventure.
(Score: 4, Interesting) by cafebabe on Monday June 23 2014, @01:32AM
That's not true. Increased instruction word length hinders some buffer overflow attacks. In the case of x86, it is possible to transform code into seven bit clean ASCII, get it past some cases of validation code and then perform a buffer overflow. This is much harder to achieve when instruction word size is 16 bits or 32 bits because fewer instructions are valid. In the case of 8 bit instructions, 37% of one byte instructions are printable 7 bit ASCII. 14% of 16 bit instructions are valid and 1.9% of 32 bit instructions are valid. A similar principle applies for UTF-8 filtering.
The downside is that longer instruction word length is harder and slower to emulate. That's a contributing factor to the dominance of x86 binaries but it shouldn't be mistaken as an equal or better solution.
1702845791×2
(Score: 2) by Dunbal on Monday June 23 2014, @09:24AM
If only you could use an operating system that was written in a way that handles buffers properly eliminating buffer overflow attacks altogether. Oh wait -
(Score: 2) by cafebabe on Tuesday June 24 2014, @10:55AM
The solution to buffer overflows is to never handle variable length data on a stack. The proper place for variable length data is a heap where it can then be attacked with heap overflows.
Obviously, I'm being facetious but I find it odd that it is easier to check buffer overflows at runtime through the use of guard values (gcc compile option -fstack-protector) rather than check buffer overflows and heap overflows at compile time.
1702845791×2