linux-kernel - Re: [PATCH 5/6] syslets: add generic syslets infrastructure

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-prev] [day] [month] [year] [list]

Message-ID: <4785AFFA.30906@garzik.org>
Date:	Thu, 10 Jan 2008 00:41:14 -0500
From:	Jeff Garzik <jeff@...zik.org>
To:	Zach Brown <zach.brown@...cle.com>
CC:	Rusty Russell <rusty@...tcorp.com.au>,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Ulrich Drepper <drepper@...hat.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@....com.au>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Evgeniy Polyakov <johnpol@....mipt.ru>,
	"David S. Miller" <davem@...emloft.net>,
	Suparna Bhattacharya <suparna@...ibm.com>,
	Davide Libenzi <davidel@...ilserver.org>,
	Jens Axboe <jens.axboe@...cle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Dan Williams <dan.j.williams@...il.com>,
	Jeff Moyer <jmoyer@...hat.com>,
	Simon Holm Thogersen <odie@...aau.dk>,
	suresh.b.siddha@...el.com
Subject: Re: [PATCH 5/6] syslets: add generic syslets infrastructure

So my radical ultra tired rant o the week...

Rather than adding sys_indirect and syslets as is,

* admit that this is beginning to look like a new ABI.  explore the 
freedoms that that avenue opens...

* (even more radical)  I wonder what a tiny, SANE register-based 
bytecode interface might look like.  Have a single page shared between 
kernel and userland, for each thread.  Userland fills that page with 
bytecode, for a virtual machines with 256 registers -- where 
instructions roughly equate to syscalls.

The common case -- a single syscall like open(2) -- would be a single 
byte bytecode, plus a couple VM register stores.  The result is stored 
in another VM register.

But this format enables more complex cases, where userland programs can 
pass strings of syscalls into the kernel, and let them execute until 
some exceptional condition occurs.  Results would be stored in VM 
registers (or userland addresses stored in VM registers...).

This sort of interface would be
* fast

* equate to the current syscall regime (easy to get existing APIs 
going... hopefully equivalent to glibc switching to a strange new 
SYSENTER variant)

* be flexible enough to support a simple implementation today

* be flexible enough to enable experiments into syscall parallelism (aka 
VM instruction parallelism <grin>)

* be flexible enough to enable experiments into syscall batching

One would probably want to add some simple logic opcodes in addition to 
opcodes for syscalls and such -- but this should not turn into Forth or 
Parrot or Java :)

Thus, this new ABI can easily and immediately support all existing 
syscalls, while enabling

Now to come up with a good programming API and model(s) to match this 
parallel, batched kernel<->userland interface...

	Jeff,	very tired and delirious, so feel free to laugh at this,
		but I've been pondering this for a while

--
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/