Ideal Architecture for Linux

Ideal Architecture for Linux

[James Crosby]

>From the point of view of one about to try to port the Linux kernel to a new
architecture:

I have recently been examining some of the existing ports of Linux to
architectures like various ARMs, SuperH, MIPS, m68k and nios2, and I
have realised that there are hardware features that are completely unused
(ARM system mode), and hardware features (kernel stack pointer in the
Motorola Coldfire port) that are completely absent, and emulated in
software.

Well aware that Linux was designed around the x86 architecture, and then
only at a later date were things restructured to make porting easier, and
with this in mind;
I am wondering what would be the best theoretical architecture to run Linux
on.

Clearly asking any 'best' question makes little sense without some kind of
benchmarks, so the things that I have in mind are:

System call (kernel entry/exit) overhead
Ease of saving and restoring a thread's context
Interrupt latency
Security
Memory requirements


Some of my own, quite conventional, thoughts are:

A stack based architecture is best, it makes nested interrupts, and general
interruptibility very easy.

Two hardware stack pointers, one for kernel stack and one for user mode
stack of each task, but maybe a third, interrupt stack.

At least two corresponding processor modes, a user mode with access only
to 'safe' instructions, and a privileged one that can do anything. But would
additional modes for interrupt handlers and system call handlers be
beneficial?

I would also consider it a significant security problem if when a task enters
the kernel, kernel data is stored on the task's user-mode stack, since the
task could fish around beyond the end of its stack and sniff private data. (This
is, if I understand correctly, the reason ARM system mode is unused.)

But on the other hand, if each task didn't need a separate kernel stack, then
there could be 4k or 8k less memory use per thread.

Is it necessarily the case that the more similar to x86, the better Linux 'fits'
the architecture?



I apologise if theoretical questions of this nature are not appropriate, and
appreciate any redirection to anywhere where they might be more so.

-- 
James Crosby

Re: Ideal Architecture for Linux

[H. Peter Anvin]

James Crosby wrote:
> A stack based architecture is best, it makes nested interrupts, and general
> interruptibility very easy.

If you mean stack-based register file, then that's *not* desirable; 
Linux depends on gcc which prefers a flat register file.  16 registers 
minimum.

> Two hardware stack pointers, one for kernel stack and one for user mode
> stack of each task, but maybe a third, interrupt stack.

Don't necessarily have to be hardware registers, although it speed 
things up.  Interrupt stacks are good.

> At least two corresponding processor modes, a user mode with access only
> to 'safe' instructions, and a privileged one that can do anything. But would
> additional modes for interrupt handlers and system call handlers be
> beneficial?

Not in Linux.

> I would also consider it a significant security problem if when a task enters
> the kernel, kernel data is stored on the task's user-mode stack, since the
> task could fish around beyond the end of its stack and sniff private data. (This
> is, if I understand correctly, the reason ARM system mode is unused.)
> 
> But on the other hand, if each task didn't need a separate kernel stack, then
> there could be 4k or 8k less memory use per thread.

No, it would just be in a different place.  Linux will *NOT* accommodate 
this model.

> Is it necessarily the case that the more similar to x86, the better Linux 'fits'
> the architecture?

No, the x86 is lacking quite a few key features.

Linux would prefer to have address space numbers, instructions for 
user-space memory access in kernel mode, and a larger page size (4K is 
really too small for modern multi-gigabyte machines.)

The design of the I/O infrastructure is another matter, too.

	-hpa