lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <146444620802190601t63ac667cpd41d834cc98d10df@mail.gmail.com>
Date:	Tue, 19 Feb 2008 14:01:21 +0000
From:	"James Crosby" <jc4.james@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Ideal Architecture for Linux

>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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ