Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Sep 1997 00:38:42 -0700 (PDT)
From:      Julian Elischer <julian@whistle.com>
To:        Simon Shapiro <Shimon@i-Connect.Net>
Cc:        FreeBSD-Hackers@FreeBSD.ORG
Subject:   Re: Fast Encryption (in kernel) seeked
Message-ID:  <Pine.BSF.3.95.970916003201.13496B-100000@current1.whistle.com>
In-Reply-To: <XFMail.970915215746.Shimon@i-Connect.Net>

next in thread | previous in thread | raw e-mail | index | archive | help
To answer this question correctly,
We need to know more details..
every algorythm has its day. It depends on what the situation is.

For example, if there will be less than 100 of these 'pointers'
outstanding at a time, different schemes would be used to the case where
there are 100000 outstanding..

can you guarentee that  each pointer given out will be 'returned'?
will it be returned only once?
what if a process dies while owning a pointer?
when does the buffer become free?
who allocates the buffers?

I have code that does all this but it's only useful to you if
what you want to do matches the goals of what I was designing for..

tell me more..

julian


On Mon, 15 Sep 1997, Simon Shapiro wrote:

> Hi! It's me again!
> 
> I have a specific integer (actually a pointer to a structure) which, for
> performance reasons, I want exported to userspace.  What happens with this
> pointer is that sometimes later it comes back to the kernel.
> 
> I want a QUICK was to encrypt it so that a melicious user cannot send a bad
> address into the kernel.
> 
> The data comes and goes via special /dev entry in the form of READ, WRITE
> and IOCTL.  The pointer in question is to a small structure and the data in
> the structure is safe from corruption.
> 
> The reasonm for this mess is that the structure is created/anihilated via
> malloc/free and the process returning it to the kernel may not be the one
> that got it from the kernel.  Instead of a key to search on, having the
> address is much faster.  The security issue is obvious.
> 
> If I could have a FAST machanism by which to ``sign'' the address, It would
> be advantageous way to handle it.  If I put just a unique signature that I
> have to then search for,  well, I knwo how to do that, and actually already
> do that.  XORing the pointer can be safe from accidents, but too easy to
> fake.
> 
> If this sounds like harebrain idea, it probably is :-)
> 
> ---
> 
> 
> Sincerely Yours,                               (Sent on 15-Sep-97, 21:44:35
> by XF-Mail)
> 
> Simon Shapiro                                                Atlas Telecom
> Senior Architect         14355 SW Allen Blvd., Suite 130 Beaverton OR 97005
> Shimon@i-Connect.Net          Voice:  503.643.5559, Emergency: 503.799.2313
> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.970916003201.13496B-100000>