Hi!
> 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
Hi!
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
Hi!
> 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
Hi!
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
On Tue, 16 Jan 2001, Ingo Molnar wrote:
> But even user-space code could use 'native files', via the following, safe
> mechanizm:
so here's an alternative to ingo's proposal which i think solves some of
the other objections raised. it's something i've proposed in the past
under the name
On Tue, 16 Jan 2001, Ingo Molnar wrote:
>
> 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
Thus spake Ingo Molnar ([EMAIL PROTECTED]):
> if you read my (radical) proposal, the identification is based on a kernel
> pointer and a 256-bit random integer. So non-negative integers are not
> needed. (file-IO system-calls would be modified to detect if 'Unix file
> descriptors' or pointers to
Thus spake Ingo Molnar ([EMAIL PROTECTED]):
> But even user-space code could use 'native files', via the following, safe
> mechanizm:
[something reminiscient of a token from a capability system]
> (this 'fingerprint' mechanizm can be used for any object, not only files.)
One good thing about
Ingo Molnar wrote:
> 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
Ingo Molnar wrote:
> - probably the most radical solution is what i suggested, to completely
> avoid the unique-mapping of file structures to an integer range, and use
> the address of the file structure (and some cookies) as an identification.
IMO... gross. We do pretty much this exact thing
On Tue, Jan 16, 2001 at 01:04:22PM +0100, Ingo Molnar wrote:
> - a less radical solution would be to still map file structures to an
> integer range (file descriptors) and usage-maintain files per processes,
> but relax the 'allocate first non-allocated integer in the range' rule.
> I'm not sure
[Ingo Molnar]
> - probably the most radical solution is what i suggested, to
> completely avoid the unique-mapping of file structures to an integer
> range, and use the address of the file structure (and some cookies)
> as an identification.
Careful, these must cast to non-negative integers,
On Tue, Jan 16, 2001 at 12:26:12PM +0100, Ingo Molnar wrote:
>
> On Tue, 16 Jan 2001, Andi Kleen wrote:
>
> > On Tue, Jan 16, 2001 at 10:48:34AM +0100, Ingo Molnar wrote:
> > > this is a safe, very fast [ O(1) ] object-permission model. (it's a
> > > variation of a former idea of yours.) A
On Tue, 16 Jan 2001, Andi Kleen wrote:
> On Tue, Jan 16, 2001 at 10:48:34AM +0100, Ingo Molnar wrote:
> > 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
On Tue, Jan 16, 2001 at 10:48:34AM +0100, Ingo Molnar wrote:
> 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
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
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
On Tue, Jan 16, 2001 at 10:48:34AM +0100, Ingo Molnar wrote:
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
On Tue, 16 Jan 2001, Andi Kleen wrote:
On Tue, Jan 16, 2001 at 10:48:34AM +0100, Ingo Molnar wrote:
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
On Tue, Jan 16, 2001 at 12:26:12PM +0100, Ingo Molnar wrote:
On Tue, 16 Jan 2001, Andi Kleen wrote:
On Tue, Jan 16, 2001 at 10:48:34AM +0100, Ingo Molnar wrote:
this is a safe, very fast [ O(1) ] object-permission model. (it's a
variation of a former idea of yours.) A process can
[Ingo Molnar]
- probably the most radical solution is what i suggested, to
completely avoid the unique-mapping of file structures to an integer
range, and use the address of the file structure (and some cookies)
as an identification.
Careful, these must cast to non-negative integers, without
On Tue, Jan 16, 2001 at 01:04:22PM +0100, Ingo Molnar wrote:
- a less radical solution would be to still map file structures to an
integer range (file descriptors) and usage-maintain files per processes,
but relax the 'allocate first non-allocated integer in the range' rule.
I'm not sure
Ingo Molnar wrote:
- probably the most radical solution is what i suggested, to completely
avoid the unique-mapping of file structures to an integer range, and use
the address of the file structure (and some cookies) as an identification.
IMO... gross. We do pretty much this exact thing in
Ingo Molnar wrote:
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
Thus spake Ingo Molnar ([EMAIL PROTECTED]):
if you read my (radical) proposal, the identification is based on a kernel
pointer and a 256-bit random integer. So non-negative integers are not
needed. (file-IO system-calls would be modified to detect if 'Unix file
descriptors' or pointers to
On Tue, 16 Jan 2001, Ingo Molnar wrote:
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
On Tue, 16 Jan 2001, Ingo Molnar wrote:
But even user-space code could use 'native files', via the following, safe
mechanizm:
so here's an alternative to ingo's proposal which i think solves some of
the other objections raised. it's something i've proposed in the past
under the name
27 matches
Mail list logo
