From what attacks is the Elbrus processor protected?

Question

Iron

I read that Elbrus was created in order to increase the security of information. So I'm wondering what kind of attacks it protects against, how these attacks are carried out and how this processor fights against them?

Answer 1

Not protected
The software is written on the basis of an outdated 2.3 kernel branch (with bugs and vulnerabilities)
Since the manufacturer does not release the software and internals for review, then it is not necessary to talk about the security of this complex

Answer 2

There is an old joke about a cowboy named Elusive Joe. Elusive, not because they can’t catch, but because no one needs him.
In real life, the Elbrus processor is already 10 years out of date, but it stands as the coolest Xenon. Those. no one in their right mind will use it, and there is not much point in attacking idiots

Answer 3

There is a so-called protected regime, inherited from the Soviet Elbrus. In the USSR, this protection in hardware complemented the protection in software. Despite the fact that Pascal and Si are the same age (1970), while the USSR was standing, they were not allowed into the country of Si, but they became very interested in Ada, accepted GOST, translated books, wrote about a dozen translators, including under Elbrus. And there was a harmony between the semantics of the programming language and the hardware.
After the hard times (the expression of Yeltsin, 1992), the potential was wasted, and the former harmony split. Elbrus survived, but the translators for it are now completely different, mainly C (C ++ was bought there from the Edison group, who make the Comeau C ++-> C translator). C was not created with security in mind, it is, in the words of the creators, a portable assembler, but they tried to screw the hardware protection inherited from the Soviet Elbrus onto this assembler. If in the case of Ada, iron organically continues the implementation of language prohibitions, then for C, screwing up protection is a hack, and for many programs in C, especially where small-town OOP is implemented, or at least a little step to the left, a step to the right, that’s all, such a program is no longer broadcast without additions. So if you take to buy Elbrus, there practically nothing works in protected mode, it is there somewhere on the side. In the MCST presentation about protected mode, a software package was described from Elbrus in completely protected mode and a regular PC with Windows 10. There was no graphical mode in protected mode, because even the primitive libraries for the framebuffer were not ported. The display was on Windows 10 over the network. For some reason, part of the code had to be ported from C++ to C.
The protection mechanism is based on the fact that in addition to the significant bits of information there are bits of tags. In RAM, they are stored in ECC bits, instead of hardware fault error control bits. From memory, tags flow into registers. Memory can be accessed from protected mode only by descriptor. The descriptor must have an appropriate tag. If there is no tag, then it is just a number that cannot be used in any other way. Any incorrect operations on descriptors will either throw an exception or break the tag, turning the descriptor into a number.
The descriptor consists of several pointers and service information. The service information includes the module descriptor. You can restrict which module can work with a particular data structure. That is, some other module can get a pointer to someone else's data structure, but it will be like a black box. For example, if this structure contains two numbers, then in order to read these numbers, you need to get a valid descriptor for the first or second number from the pointer to the data structure, and then read the contents of the new pointer. The inter-module protection system does not allow a foreign module to make such a conversion. This means that bypassing the desired module, you can neither read nor write inside. However, operations with the numerical representation of the descriptor are available. For example, if there is some other pointer, you can, by comparing numerical representations, find out
The data descriptors form a two-level model. For different levels, two different types of descriptor. In the general case, some kind of (two-level) data structure is an array of class instances. An array descriptor has a current element, and there are array bounds. The current element, according to the rules of the C language, can be outside the bounds. It is fine for intermediate calculations, but not for dereferencing. For a massive descriptor, address arithmetic works. But the size of the elements is fixed.
Each element of the array is, in the general case, some instance of the class, and is described by an object descriptor, in which, instead of the array boundaries, there are other pointers needed for the OOP implementation. Of course, the field of an object can be an array, and it turns out such a nesting doll. The operating system and runtime library play a special role. The processor is not that smart, and by no means any rules for converting descriptors are hardwired into its hardware. Many operations are actually performed in the runtime library, which is endowed with additional privileges for this. She knows about what types are in the modules, and how, and to whom it is possible to convert descriptors.
Also in Elbrus there is a way to mark memory as uninitialized to catch errors when accessing it.
Finally, there is also a stack frame index for the data on the stack, so dereferencing the handle to the stack frame of the returned function will not work. This error will be caught too.
To summarize, a descriptor contains:
1. a normal pointer
2. the type of the descriptor (array/object)
3. a module descriptor
4. a stack frame index
5. either pointers to array bounds or pointers to information for OOP
1 and 5 give at least 3 ordinary pointers in one descriptor, and 2-4 finish the descriptor with information to the eyeballs. It is known that the descriptor size is 128 bits. Everything shows that whatever one may say, but 3 64-bit pointers, even if you cut them to 48 bits, well, they don’t fit in any way. Maybe 36 bits can still be crammed in, but it seems not. So the protected mode of Elbrus is 32-bit or not much different from that.
However, the unprotected mode is also protected a little stronger than on other processors. In unprotected mode, the stack is slightly more protected than usual.
By and large, many of the errors that Elbrus provides protection against are specific to C and C ++. C and C++ programmers create problems, and then Elbrus appears and, like, heroically solves them. Well, that's bullshit if you think about it. In a good way, it is necessary to write in Ada and demand the same from others. How many years there are buffer overflow errors, so many years there is a solution for them (Pascal and Sea peers). Considering that in the protected mode of Elbrus almost nothing special just works, it turns out that under Elbrus to write new software in C, which is in Ada, you have to make tangible investments of labor at least as you have to. But on Ada it will be protected everywhere, not only on Elbrus, and there are 64 bits on Ada. And for increased security, there is a verifiable subset of SPARK, which has been booming lately. SPARK used to be quite oaky. If something cannot be verified, then SPARK did not have it. For example, there were no ordinary containers, as in the Ada language, but there were their own, occupying the maximum memory size at once. But now ParaSail and Rust are preparing to borrow safe pointers, so SPARK will have more freedom with dynamic memory.
Hardware protection in Elbrus is not unique. There was once an Intel i960MX. On the basis of MIPS in Cambridge, CHERI was developed, and it is still on sale. Unlike Elbrus, they don't keep secrets there. You can download the emulator, documentation and development tools directly from the site. Take, look, study whoever you want. And this is not Russia under sanctions, this is an influential British university. None of this helped him occupy any particularly significant niches. Verification does not have a 1:1 match with hardware control, they would be better off complementing each other than forcing them to choose, but it is clear that real buyers, aviation (Boeing), and for some time unmanned vehicles (nVidia) rely on verification more than hardware protection.

Answer 4

In general, the Elbrus architecture differs from Intel\AMD and is based on the SPARC architecture. To be able to work with existing software, it implements a translator of x86-code into its own.
There was an article on Habré on the history of the creation of processors (unfortunately, it was not possible to find it quickly), it talked about Soviet developments, existing technologies and their prospects. So Elbrus is an attempt to create a processor based on the existing Soviet developments, taking into account the achievements of science, without using the patents of Intel, AMD, ARM, etc. Accordingly, at this stage it is suitable only for military and academic purposes.
You can also see the article .

Answer 5

Well, how can I say, the processor does not go to the ground with the attackers, but it is very interesting in itself.
Especially when you consider the number of executable instructions in fresh processors.
By the way, they already seem to be coming soon.
And the larger their production is, the lower the cost, and therefore the justification for use, will grow in those areas related to security, where it is necessary.