l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tread/Task IDs


From: Marcus Brinkmann
Subject: Re: Tread/Task IDs
Date: Tue, 6 May 2003 23:37:43 +0200
User-agent: Mutt/1.5.3i

Hi,

of course I can not answer the question why 64 bit data types are not used
on 32 bit arches, except maybe that the word size on 32 bit arches is 32
bit, and thus that's the best type to use for every other reason than the
limitation that imposes on the number of bits (like performance, atomicity,
alignment, etc).

On Tue, May 06, 2003 at 04:37:31PM -0400, address@hidden wrote:
> I admit I have only dabbled in kernel space and I usually do cryptographic
> stuff in userspace with 128-bit or 256-bit IDs.  Maybe I'm just jaded from
> huge IDs.  However, it would seem to me that there would be many fewer hacks
> if IDs were at least 32-bits, if not 64-bits.

The whole thread id is 32 bit on 32-bit arches.
 
> I'm sure the X.2 API was very well thought out, I'm just a little surprised
> at the kludges HURD is forced to consider due to the L4 API.  I'd like to
> see what I'm missing.

I am not sure something fundamental would change even with the 64 bit
interface.  Surely the race would become much harder to exploit, but
probably still possible (I only did a quick calculation).  Now, if you give
me timer resolution for the version id part, I would be happy, but that
would require 64 bits for the version part alone (thus 96 or more bits for
the whole thread id).

Thanks,
Marcus
-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]