Spectre / Meltdown

Unless you are doing to simultaneously run multiple untrusted users on it, I don't think you need to worry even if it does have the problem.

-- Those who want slavery should have the grace to name it by its proper name. They must face the full meaning of that which they are advocating or condoning; the full, exact, specific meaning of collectivism, of its logical implications, of the principles upon which it is based, and of the ultimate consequences to which these principles will lead. They must face it, then decide whether this is what they want or not.

Ayn Rand.

Googling the raspberry forum, it appears that it is suseptible to spectre but not meltdown.

This has more info...

"gareth evans" wrote

| Is it true that the RPi4 is susceptible to these | security attacks but that no previous versions are?

Simple rule: If you allow javascript or other executable code online, you're a sitting duck. If you also store private data on your computer, use credit cards online, bank online, etc, you're a sitting duck with something to lose.

That might seem extreme or paranoid, but it's just the facts. People want to believe computers can be made safe. Executable code cannot be made safe. And these days we're going in the opposite direction, toward the cloud model of computing based on corporate systems, where the network is considered safe while your family or housemates or co-workers are considered to be risks.

When you combine the corporate security model with SOHo usage you get crazy risk.

I'm really disapointed that there hasn't been more work done on both hardware as OS design to make cross-process interference impossible and to properly implement hardware protection rings to stop application-level code clobbering the OS and the OS from clobbering to low-level drivers.

This stuff isn't new: systems have been built that way since the early to mid 70s. Two examples I know of are the ICL 2900 series and the IBM Future Series.

The ICL 2900 architecture supported all the features I mentioned above.

The IBM implementation didn't have hardware rings of oritection but did run each process in its own address space. It was initially killed before being revived as the System/38, which morphed into the AS/400 before being renamed as the iSeries.

The IBM approach still exists as Power series chips, but the 2900 architecture is now almost irretrievably lost. Pity, because both systems were almost bulletproof in terms of limiting the damage a piece of bad code could do.

Linux on X86 chips should be able to provide some protection via the three protection rings they (used to?) provide, but does Linux use them to prevent one process clobbering another? I'd hope so, but have never seen any information about that.

--
Martin    | martin at 
Gregorie  | gregorie dot org

describes which cores are susceptible to which attacks. The variants that the Pi4?s CPU are vulnerable to are as follows:

• Variants 1 and 2 (CVE-2017-5753 and CVE-2017-5715) are Spectre. An attacker can bypass validity checks and access data that?s supposed to be secret.

• Variant 3A (CVE-2018-3640) is essentially Meltdown but for registers instead of memory. An attacker can bypass CPU-level privilege checks and read access data that is supposed to be secret.

• Variant 4 (CVE-2018-3639) is a speculative store bypass. An attacker can access data that was supposed to have been overwritten.

The other Pi CPU cores are not listed and therefore not vulnerable to any known speculation-based attacks.

Since the original Spectre/Meltdown research, a _lot_ of variants have been identified. It?s likely that there are more to come. Arm?s record has been very good here, but it?s not impossible that future issues may impact Arm cores too.

--
https://www.greenend.org.uk/rjk/

At least the 32 bit Linux kernel starts by effectively by-passing the segmentation and ring protection mechanism and using only the paging.

The 80286 has a proper ring-protection mechanism, but it was bastardized in the PC/AT, and the 80386 already gave up with the virtual-86 mode.

--

-TV

It doesn't help when pipelined processor optimisations break the barriers.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
The computer obeys and wins.                |    licences available see 
You lose and Bill collects.                 |    http://www.sohara.org/

Privilege levels/modes/ringsetc don?t make sense as a process-to-process isolation technique; they only isolate the kernel from user processes. Instead process-to-process isolation in Linux (and anything else vaguely modern) uses the virtual memory system - i.e. running each process in its address space. The situation in Windows is the same.

The microarchitectural attacks discussed in this thread are unintended consequences that undermine these and other isolation techniques.

--
https://www.greenend.org.uk/rjk/

Of course - but in combination with running each process in its own address space and, passing all call parameters on the stack and with allowing call access only to anything in a more privileged level, you get really good isolation with minimal overheads.

Good to know: its not at all obvious from the the system descriptions I've seen that (a) Linux or windows has ever made any use of protection rings and (b) to what extent processes have their own address space.

About I know beyond that is that systems capable of redefining the architecture on a per-VM basis, another nice-to-have, has really only been implemented by two mainframe families (Burroughs B series and ICL

2900).

Burroughs B series used it to to run COBOL programs in byte-addressed memory space and FORTRAN or Algol programs in word-addressed memory, while the ICL 2900 could run George 3 (24 bit word memory using 6-bit characters, 8 24 bit accumulators and no stack) alongside VME/B (byte- addressed memory, EBCDIC byte codes, stack-based architecture with a single resizable accumulator).

Indeed.

--
Martin    | martin at 
Gregorie  | gregorie dot org

Another argument in favour of RISC rather than CISC?

--
Martin    | martin at 
Gregorie  | gregorie dot org

On Fri, 28 Aug 2020 18:26:26 -0000 (UTC), Martin Gregorie declaimed the following:

If ARM is considered RISC, it is still pipelined:

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

It?s not related to RISC vs CISC.

--
https://www.greenend.org.uk/rjk/

A lot of things are not obvious if you don't bother to find out. Where have you looked?

@Mayayana, I am becoming a fan of you.

Windows was certainly designed with protection rings, at least User and Kernel Modes. AIUI these do make use of CPU protections and require an expensive interrupt type operation to move from one ring to the other. I assume Linux/Unix is the same.

MS has periodically sacrificed security by giving code access to kernel mode in order to boost performance. Early graphics device drivers, for games, and later IIS.

From an App Dev viewpoint it is so important to me that I don't think I have considered it in the last 25 years. :-)

FWIW Kernel mode has the ability to get around protections offered by process private virtual memory.

ARM is pipelined, I think all chips are now.

FWIW Risc architectures pioneered (longer) pipelining. In particular I think there was an idea about optimising compilers being able to do better branch prediction.

There is a solution that significantly decreases risk when allowing JavaScript in a web browser:

Run the browser from a different (browser-only) user account that has very strictly controlled access to files owned by your normal account.

It takes a little bit of scripting to make it work. For one thing, you need to give the browser-only account XAUTHORITY in order to be able to display the browser.

If you use any applications (like a GUI email client/MUA) you'll need to do something if you want cross-application links to continue to work, but I don't do that, so I don't know solutions.

Also, you will need to set permissions on your directories and files to block the browser-only account access to your files--except maybe one or only a few directories that can act as couriers between the accounts.

For extra points, I have read Usenet posts from someone who has a separate browser account for each of his bank(s) and for each other sensitive website.

--
Robert Riches 
spamtrap42@jacob21819.net 
(Yes, that is one of my email addresses.)

Or just use Qubes.

/ Bud /

a1=S0 b1=[1..2,'L0L'] a2=2*a1 a3=S1.4#b1 a4=(a2,a3) a5=64*a4