From: Aaron Patterson on
On Fri, Feb 19, 2010 at 04:41:16PM +0900, Chad Perrin wrote:
> I'm writing a utility that needs to use secure memory (that is, won't
> swap to disk). Is there a "best practices" way to do this with Ruby,
> some common library that could be used for this purpose, et cetera?

What do you need to do exactly? Are you going to be allocating the
memory yourself? If so, you might want to look for wrappers around
mlock, and use the mmap gem.

If you're talking about the entire ruby VM, I would suggest compiling
your own Ruby, but modifying the memory allocators to use something like
secmalloc:

http://www.jabberwocky.com/software/secmalloc/

--
Aaron Patterson
http://tenderlovemaking.com/

From: Ryan Davis on

On Feb 18, 2010, at 23:41 , Chad Perrin wrote:

> I'm writing a utility that needs to use secure memory (that is, won't
> swap to disk). Is there a "best practices" way to do this with Ruby,
> some common library that could be used for this purpose, et cetera?
>
> Thanks in advance for any help.

Don't worry about it and employ the OS's option for secured virtual memory?



From: Ryan Davis on

On Feb 19, 2010, at 15:51 , Chad Perrin wrote:

> On Sat, Feb 20, 2010 at 08:39:21AM +0900, Ryan Davis wrote:
>>
>> On Feb 18, 2010, at 23:41 , Chad Perrin wrote:
>>
>>> I'm writing a utility that needs to use secure memory (that is, won't
>>> swap to disk). Is there a "best practices" way to do this with Ruby,
>>> some common library that could be used for this purpose, et cetera?
>>>
>>> Thanks in advance for any help.
>>
>> Don't worry about it and employ the OS's option for secured virtual memory?
>
> Is there a means of doing so from within Ruby so that the OS-specific
> details are abstracted away, thus allowing for a maintainable, portable
> tool?

AFAIK, secured virtual memory is a system-wide needs-a-reboot type of thing. So other than good doco, I think the answer defaults to "no". It is the route I'd go. The software will be as clean as it can be, easy(ier) to security audit, etc. All with the caveat, that you need to run it in a secured environment. Given the original requirements, that just seems common sense/expected to begin with.