linux-kernel - Re: atomic RAM ?

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <v2u8bd0f97a1004081836na92954bdu4ed473816dc831b9@mail.gmail.com>
Date:	Thu, 8 Apr 2010 21:36:54 -0400
From:	Mike Frysinger <vapier.adi@...il.com>
To:	Michael Schnell <mschnell@...ino.de>
Cc:	linux-kernel@...r.kernel.org,
	nios2-dev <nios2-dev@...c.et.ntust.edu.tw>
Subject: Re: atomic RAM ?

On Thu, Apr 8, 2010 at 03:32, Michael Schnell wrote:
>  - new "custom" processor instructions can be defined that might work
> atomically, as well not interruptible as kind of bus-locking for SMP use
>  - these custom instructions can't access the memory in normal way
> (through the MMU and the cache).
>
> So to implement atomic instructions a dedicated RAM area would be needed
> to hold the atomically accessible data. Same can't be accessed by the
> CPU in other ways. This RAM area would be implemented with the new
> atomic instructions and be located within the FPGA and thus could
> accessed very fast (no cache issues).
>
> Of course this would need for the Kernel and the libraries to avoid any
> access to that RAM area with normal instructions. All code would need to
> use the set of "atomic" macros to access that RAM. Here I suppose we
> would need some additional atomic Macros such as "atomic_malloc()",
> "atomic_read_word()" etc, which, with normal archs would just reproduce
> the standard code.
>
> Of course the size of the "atomic RAM" would be limited and thus a
> system error would be generated if same would be exhausted. I don't
> think that, with the intended "embedded" use, this would be a serious issue.
>
> I feel that thinking about this could be viable task - even if this
> might ask for some modifications in the global arch-independent Kernel
> and/or library code, as I suppose this is the only way to allow for
> implementing an SMP design with NIOS and similar archs. (Happily these
> modifications would be "compatible" by design as with any existing arch
> just the existing code would be reproduced by the new Macros and so
> their use is strictly optional with any arch other than those that would
> profit from the new implementation.)

the Blackfin already has such an instruction (TESTSET), but since it
has restrictions (cannot be used safely on cached memory), we found it
unusable as a generic solution.  this is why we went to the userspace
fixed atomic code region.

the only time we use this instruction is with the Blackfin SMP port,
and only as an inter-core lock (so it has a fixed address and there is
only one such lock).

i think you underestimate the task of customizing every userspace
point that may want atomic instructions.  and no matter what sized
atomic region you pick, having it arbitrarily fail at runtime because
applications have "too many" locks is a poor solution.
-mike
--
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/