OS wiith no virtual memory

[nullplan]

AKAIK, a mov to cr3 invalidates the whole TLB. Correct me if I'm wrong,

You are wrong if global pages are supported and you are using them. Only the TLBs for non-global pages will be flushed.

[Korona]

PowerPC64 allows operation in 64-bit real-addressing mode (bypassing all forms of paging), but only in System State. Any operation that changes to Problem State automatically turns on the MMU for data and instructions (those are separate on PPC). It allows you to run without MMU, but also without any form of memory protection, such that processes cannot even opt into any kind of self-protection. At work, we are using OS-9 on PPC32, and OS-9 does not support virtual memory (nor 64-bit operation), but it still runs the MMU (and is identity mapping everything), just to be able to run in Problem State (preventing the execution of privileged instructions) and gain some kind of separation between processes (even though the _os_permit() system call breaks that again, but that is neither here nor there).

The performance benefits of this are dubious. We use a Freescale e300 processor, which has TLB miss interrupts and no automatic page table search. Which is good, since it allows the OS to not use IBM's hashed page table design, but since memory protection is a thing, a TLB miss interrupt handler must still look up if the current context is allowed to access the address it wanted to access, in the way it wanted to access it. So the performance of that depends on the data structure used for the memory protection records. So the whole thing ends up being not a whole lot faster than just supporting normal virtual memory, since the physical address to a given virtual address might be clear, but the access permissions still aren't. Since physical address and access permissions can be squished into the same quantity, looking up one takes as long as looking up the other.

Makes sense, thank you for the information. I think this illustrates an important point: even if you do not need virtual memory, you probably do want protection. The question of memory protection was largely ignored in the posts above but the thing is (and I only now thought about it this way): if you already have fine-grained (= page level) protection, you get virtual memory for free.

EDIT:

As far as reduced register set goes, i386 is just, well, special . Whenever I do anything with ARM, I'm shocked by how may registers there are

That's also true on ARM, isn't it? 64-bit ARM has 32 GPRs (while 32-bit ARM only has 16). Plus, modern ARM features are increasingly gated behind 64-bit mode (same for x86_64).

[thewrongchristian]

AKAIK, a mov to cr3 invalidates the whole TLB. Correct me if I'm wrong,

You are wrong if global pages are supported and you are using them. Only the TLBs for non-global pages will be flushed.

And on processors that support PCID, TLB entries are tagged with the current PCID. In fact, with PCID, does changing cr3 flush anything at all (perhaps all entries that match the current PCID only?)

[nexos]

I forgot about PCID . That definitely sounds like a good feature, and doesn't it mitigate Spectre? ARM32's register set is still great compared to i386's 6 GPRs (if you exclude EBP).

[eekee]

I forgot about PCID . That definitely sounds like a good feature, and doesn't it mitigate Spectre? ARM32's register set is still great compared to i386's 6 GPRs (if you exclude EBP).

Which 6? I was going to exclude even ECX because it's needed for string instructions, thus not completely general-purpose. AFAIK other architectures let you choose the register to count with, which I think that eases register allocation. Although even 6 is less than half ARM32's. If I remember right, it's less than the 68000 had, and the 68000 was marketed as 16-bit.

[nullplan]

Which 6? I was going to exclude even ECX because it's needed for string instructions, thus not completely general-purpose.

Well no, that is just x86 being its normal CISC-y self. Therefore some instructions have implicit operands, and sometimes you can't change them. Yes, ECX is an implicit operand of a prefix, which is its own kind of weirdness, but all of the string operations use EDI, ESI, or EAX as implicit operands, multiplication and division often use EAX and EDX, as do many of the operations accessing special registers, like RDTSC, RDMSR, and WRMSR, and let us not even speak of CPUID. X86 has 8 general-purpose registers (EAX, EBX, ECX, EDX, ESI, EDI, EBP, and ESP), but ESP is typically bound up to serve as stack pointer, and cannot be used for many other things. I mean, you can, if you block signals/interrupts and have a way to find the stack pointer again afterwards. Usually it's not worth it.

But then, that is usually the case with bound-up general purpose registers, isn't it? ARM has 16 GPRs, but one of them is the stack pointer, and one is the program counter, so if you exclude those since they are bound up, it is only 14, so one less than AMD64 has! And Thumb 1 only has access to 8 of them, with stack pointer and PC being included in them. So X86 is about as bad as Thumb 1.

BTW, PowerPC32 has had 32 GPRs since inception. Of these, typically R1 is used as stack pointer, and R2 and R13 are used as quasi-constant pointer registers (beats me why these particular ones, though), but that still leaves 29 registers to do whatever with.

[Korona]

Note that x86 microarchitectures have many more than 8 GPRs. For example, Skylake maps the 8 GPRs (or 16 GPRs in 64 bit mode) to 180 physical integer registers by register renaming.

[bloodline]

Although even 6 is less than half ARM32's. If I remember right, it's less than the 68000 had, and the 68000 was marketed as 16-bit.

Architecturally, the 68000 is a 32bit CPU (though, the original 68000 and 68010 were implemented using 16bit Logic, that was hidden from the programmer). The rest of the family were fully 32bit.

The 68k ISA has a slightly strange register structure, with sixteen 32bit registers (one of which is always the stack pointer) split into 8 Data registers and 8 Address registers. You can for the most part treat these all as general purpose registers, but they do behave differently when performing certain operations and predictably with specific addressing modes (the clue is in the name).

[linguofreak]

How much would an OS without virtual memory speed up memory accesses?

It's not possible to answer this question without knowing what CPU the OS will be running on and what programs it will be running.

In theory, for a very simply designed CPU with a very simply designed paged MMU and n-level page tables, paging would cut the speed by a factor of n+1. In practice, pretty much every CPU that bothers to do paging has a way to quickly recall the physical addresses for virtual pages that were recently accessed, and most programs tend to have large clusters of accesses to addresses in close proximity to one another, and this means that the vast majority of all memory accesses happen just as quickly as if there were no paging. Now, a program that just keeps reading random memory locations with no pattern will seldom hit the same page twice, and will see the full slowdown from paging, but such programs are relatively rare.

Many OSes will swap pages out to disk if the system runs out of memory, so that the system can use disk space as extra memory. Disk access is very slow (particularly magnetic disks, which can be reasonably fast if the head is already positioned to access the requested data, but take a long time to reposition the head), so if a program (or set of programs) is actively using more memory at a given time than the system has RAM, things can slow down by a factor of thousands. The hypothetical program that accesses a random address every tine could even see a slowdown by a factor of a million. Once again, however, most programs tend to make memory accesses in clusters of close-together addresses, so these types of worst-case slowdowns are rare (and you'll never see swap slowdowns at all if the computer is never using more memory than it has available RAM).

[bzt]

How much would an OS without virtual memory speed up memory accesses?

It's not possible to answer this question without knowing what CPU the OS will be running on and what programs it will be running.

In general, yes. However we surely could anticipate serious speed up because separate address spaces means memory buffers must be copied (or at least mapped in CoW manner) from one address space into another. But without MMU using a single address space it's enough to just pass a simple pointer around in a register because all memory buffers are directly accessible for all tasks.

Cheers,
bzt

[nexos]

How much would an OS without virtual memory speed up memory accesses?

It's not possible to answer this question without knowing what CPU the OS will be running on and what programs it will be running.

In general, yes. However we surely could anticipate serious speed up because separate address spaces means memory buffers must be copied (or at least mapped in CoW manner) from one address space into another. But without MMU using a single address space it's enough to just pass a simple pointer around in a register because all memory buffers are directly accessible for all tasks.

Cheers,
bzt

And have the user's data get tampered with.... Sounds like a security nightmare .

[thewrongchristian]

However we surely could anticipate serious speed up because separate address spaces means memory buffers must be copied (or at least mapped in CoW manner) from one address space into another. But without MMU using a single address space it's enough to just pass a simple pointer around in a register because all memory buffers are directly accessible for all tasks.

Cheers,
bzt

And have the user's data get tampered with.... Sounds like a security nightmare .

I suppose if you have no MMU, security is not your primary concern, as you have to trust your own user code anyway.

But it begs the question. With a 64-bit address space, and with position independent user code located at random addresses, and with some page based access checking (would need MMU obvs) is a single address space OS feasible and reasonably secure (at least for the purposes of regular consumer code?)

A malicious app would need to know where in the 64-bit address space to look, and the OS could trap seemingly random address probing to catch address space scans. The OS could at least make it statistically infeasible to scan large portions of memory without being noticed.

[bloodline]

However we surely could anticipate serious speed up because separate address spaces means memory buffers must be copied (or at least mapped in CoW manner) from one address space into another. But without MMU using a single address space it's enough to just pass a simple pointer around in a register because all memory buffers are directly accessible for all tasks.

Cheers,
bzt

And have the user's data get tampered with.... Sounds like a security nightmare .

I suppose if you have no MMU, security is not your primary concern, as you have to trust your own user code anyway.

But it begs the question. With a 64-bit address space, and with position independent user code located at random addresses, and with some page based access checking (would need MMU obvs) is a single address space OS feasible and reasonably secure (at least for the purposes of regular consumer code?)

A malicious app would need to know where in the 64-bit address space to look, and the OS could trap seemingly random address probing to catch address space scans. The OS could at least make it statistically infeasible to scan large portions of memory without being noticed.

I’m going to explore what options to improve stability and security in a single address space operating system might be implemented... I don’t hold out much hope for any single solution better than the now traditional memory protection model, but it should be fun to explore.

[nexos]

A malicious app could overwrite all of memory with zeroes, no matter what you do. No MMU almost means no security .

[nullplan]

A malicious app could overwrite all of memory with zeroes, no matter what you do. No MMU almost means no security .

Even better: A malicious app could overwrite the IDT to register one of its own functions as interrupt handler, then call that interrupt. Thereby usurping kernel privileges and taking over the whole machine.