Computing desk
< June 24	<< May \| June \| Jul >>	June 26 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

June 25

Intel Run Sure Technology

The Intel Xeon 6244 processor[1][2] has "Run Sure Technology". The Intel Xeon 4208 processor[3][4] does not. But what, exactly, is "Run Sure Technology"?

The pages above say

"Intel Run Sure Technology, includes advanced RAS (reliability, availability and serviceability) features that deliver high reliability and platform resiliency, to maximize uptime of servers running mission-critical workloads." Not very specific.

[5] says things like

"Intel Run Sure Technology features Resilient System Technology that integrates processor, firmware, and software layers to help diagnose fatal errors, contain faults, and automatically recover to keep the server operating" That's nice, but it tells me nothing about whatever secret sauce the Xeon 6244 has and the Xeon 4208 lacks. If I compare the two what difference will I see? Additional instructions? Additional registers? Something different in the error reporting?

Can anyone find a source that explains what is special about a processor with Intel Run Sure Technology and/or Intel Resilient System Technology? Does it have anything to do with Machine Check Architecture? --Guy Macon (talk) 18:32, 25 June 2019 (UTC)[reply]

Here's an Intel page aimed at a significantly more technical audience: RAS Integration and Validation Guide (for the slightly older "generation 2" version). The "Run Sure" marketing name is applied to Generation 3 of this technology. "Run Sure" is essentially a bit of marketing-ese, primarily aimed at big companies who build computer systems commercially. These big companies can hire system programmers to worry about the details, which is to say, selecting a specific processor SKU and then writing very specific system-software that uses these better error-recovery methods to reduce the statistical rate of full system reboots - the phenomenon that an end-user might call a "kernel panic" - even if it is not actually a kernel panic. Intel is essentially asserting that its low-level firmware technology can improve, statistically, the likelihood of software recovery from a serious error that would otherwise require a hardware reboot - and if you believe in that amorphous mythical animal that we call "software," a hardware reboot is something that should never occur on a modern computer.

If you're a kernel hacker, here's the official linux implementation of RAS-tools for Intel. If you're not a kernel hacker, and this stuff looks pretty unfamiliar - don't worry. Normally, this kind of thing is handled by the people who build your computer and write your operating system for you.

To an end-user who purchases a finished computer product and installs a "standard" operating system that is written by somebody else, these details are entirely hidden by opaque layers of firmware and software; the broad take-away is that the whole system should be more reliable, provided that you read the fine print: "No computer system can provide absolute reliability, availability, or serviceability..."

Nimur (talk) 16:56, 26 June 2019 (UTC)[reply]

You might also be looking for the Software Developer's Manual. Volume 4 contains the Model Specific Registers; Volume 4, Chapter 2.17 contains the Xeon Scalable family MSRs; and chapter 1 lists a few more books for recommended reading. These books are, literally and metaphorically, the listings of the differences between, e.g., these two steppings/models of CPU.

This is heavy lifting reference - it's not so much "light reading" as much as "the sort of book one would hire a team of system programmers to read and report about, prior to making a heavy investment in a strategic technology;" or more probably, "the sort of book that professional team of engineers stares at during the wee hours of the morning while debugging a new computer platform, because nobody thought strategically about a technology choice ahead of time."

Nimur (talk) 17:32, 27 June 2019 (UTC)[reply]

Password-protected data

Imagine that in a library there is a restricted section and the rules say that you need permission to access it. In such a section, one who doesn't have permission but breaks through or gets around the security will reach the books, because they are objectively there.

What if some digital data is password-protected? Again, it is objectively there, encoded in the form of bytes or whatever. Can one get it despite not having the password, at least theoretically? --Qnowledge (talk) 23:00, 25 June 2019 (UTC)[reply]

If the "library" uses the strongest known encryption (one-time pad) the attacker will only access a bunch of apparently random garbage. There is no way to ever read the data, even theoretically and even with an infinitely powerful computer and an infinite amount of time. If the "library" uses Strong cryptography and we ignore the possibility of a future technological breakthrough that "breaks" the encryption (in the case of Advanced Encryption Standard many many people have looked very hard indeed and failed to find one) decoding even a tiny part of the "library" will take far longer than the age of the universe using a computer larger than the solar system and as fast as it is possible for any computer to be. --Guy Macon (talk) 00:20, 26 June 2019 (UTC)[reply]

However, the "if" is important. The original poster did not specify that encryption was used. --76.69.117.113 (talk) 00:34, 26 June 2019 (UTC)[reply]

Qnowledge, yes, as Guy Macon and 76.* say, there are basically two ways to implement such access controls: 1) implement an authentication check before granting access to the data, which creates the possibility of somehow bypassing the check; or 2) encrypt the data, in which case it can't be decrypted without the encryption key, which might or might not be derived from the password. Encrypting is more solid protection and the algorithms are very strong, but you then have to deal with a lot of issues with key management. For example, if the key is derived from the password and the user forgets their password, how do you reset it? And if the key is ever loose in as complicated a software environment as a PC or smartphone, it can probably be extracted, so it is sometimes wrapped in special hardware like the IOS#Secure_Enclave. But even then, it can still be attacked (see Cellebrite). It's a constant spy-vs-spy drama. 173.228.123.207 (talk) 07:51, 26 June 2019 (UTC)[reply]

One obvious way for somebody to get the PW is if an authorized person shares it with them, either intentionally, or perhaps by writing it down so they can remember it, in a less-than-secure location. A system where the PW is changed after each access would reduce this risk.

Another risk is that the authorized person could copy the content and distribute it (or have it copied against their will from them).

One situation where this occurs is where the US executive branch wants to show top-secret info to members of Congress, but doesn't want it getting out to others. There the approach has been to physically secure written copies, and only let in authorized Congressmen without any recording devices, even paper and pencil. (They could still memorize it, but most people can't recall much detail. Only those with eidetic memory would be a concern.) SinisterLefty (talk) 18:07, 27 June 2019 (UTC)[reply]

This [6] is always happening. 92.31.143.72 (talk) 10:52, 28 June 2019 (UTC)[reply]