[lkml]   [2001]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread

On Mon, 15 Jan 2001, Linus Torvalds wrote:

> > _syscall4 (int, sendpath, int, out_fd, char *, path, off_t *, off, size_t, size)

> You want to do a non-blocking send, so that you don't block on the
> socket, and do some simple multiplexing in your server.
> And "sendpath()" cannot do that without having to look up the name
> again, and again, and again. Which makes the performance
> "optimization" a horrible pessimisation.

yep, correct. But take a look at the trick it does with file descriptors,
i believe it could be a useful way of doing things. It basically
privatizes a struct file, without inserting it into the enumerated file
descriptors. This shows that 'native files' are possible: file struct
without file descriptor integers mapped to them.

ob'plug: this privatized file descriptor mechanizm is used in TUX [TUX
privatizes files by putting them into the HTTP request structure - ie.
timeouts and continuation/nonblocking logic can be done with them]. But
TUX is trusted code, and it can pass a struct file to the VFS without
having to validate it, and TUX will also free such file descriptors.

But even user-space code could use 'native files', via the following, safe

1) current->native_files list, freed at exit_files() time.

2) "struct native_file" which embedds "struct file". It has the following

struct native_file {
unsigned long master_fingerprint[8];
unsigned long file_fingerprint[8];
struct file file;

'fingerprints' are 256 bit, true random numbers. master_fingerprint is
global to the kernel and is generated once per boot. It validates the
pointer of the structure. The master fingerprint is never known to

file_fingerprint is a 256-bit identifier generated for this native file.
The file fingerprint and the (kernel) pointer to the native file is
returned to user-space. The cryptographical safety of these 256-bit random
numbers guarantees that no breach can occur in a reasonable period of
time. It's in essence an 'encrypted' communication between kernel and

user-space thus can pass a pointer to the following structure:

struct safe_kpointer {
void *kaddr;
unsigned long fingerprint[4];

the kernel can validate kaddr by 1) validating the pointer via the master
fingerprint (every valid kernel pointer must point to a structure that
starts with the master fingerprint's copy). Then usage-permissions are
validated by checking the file fingerprint (the per-object fingerprint).

this is a safe, very fast [ O(1) ] object-permission model. (it's a
variation of a former idea of yours.) A process can pass object
fingerprints and kernel pointers to other processes too - thus the other
process can access the object too. Threads will 'naturally' share objects,
because fingerprints are typically stored in memory.

3) on closing a native file the fingerprint is destroyed (first byte of
the master fingerprint copy is overwritten).

what do you think about this? I believe most of the file APIs can be /
should be reworked to use native files, and 'Unix files' would just be a
compatibility layer parallel to them. Then various applications could
convert to 'native file' usage - i believe file servers which have lots of
file descriptors would do this first.

(this 'fingerprint' mechanizm can be used for any object, not only files.)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:18    [W:0.177 / U:6.884 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site