FAQ
Hi, I'm working on an application that deals with some data that cannot
ever be written to a pagefile by the os without completely negating the
entire purpose of the application.

I'm curious if go has a package, or really anything, to prevent this.

I realize that it might be possible to encrypt in-memory and decrypt only
when necessary but I imagine that might not be totally reliable given that
the garbage collector copies and destroys memory at its own will.
Perhaps I am just being paranoid but one can never be too safe.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Bob Hemington at Aug 14, 2013 at 4:33 am
    As far as I know the problems you describe are correct (with GC doing what
    it wants too, and memory ending up in page files).

    I think the most feasible approach would be to find out how to do what you
    want in C, then use cgo.

    Bob
    On Tuesday, August 13, 2013 8:28:06 PM UTC-7, kyl...@gmail.com wrote:

    Hi, I'm working on an application that deals with some data that cannot
    ever be written to a pagefile by the os without completely negating the
    entire purpose of the application.

    I'm curious if go has a package, or really anything, to prevent this.

    I realize that it might be possible to encrypt in-memory and decrypt only
    when necessary but I imagine that might not be totally reliable given that
    the garbage collector copies and destroys memory at its own will.
    Perhaps I am just being paranoid but one can never be too safe.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kyleveb at Aug 14, 2013 at 4:39 am
    I see. I was really hoping for a pure go way. I'll see if I can use some c
    later on but for now I'll have to put a big warning label on it saying
    "DON'T LET ANYONE ACCESS YOUR PAGEFILE/GAIN PHYSICAL ACCESS TO YOUR
    SYSTEM/BE MALICIOUS TO YOUR PHYSICAL HARDWARE"
    On Tuesday, August 13, 2013 10:33:12 PM UTC-6, Bob Hemington wrote:

    As far as I know the problems you describe are correct (with GC doing what
    it wants too, and memory ending up in page files).

    I think the most feasible approach would be to find out how to do what you
    want in C, then use cgo.

    Bob
    On Tuesday, August 13, 2013 8:28:06 PM UTC-7, kyl...@gmail.com wrote:

    Hi, I'm working on an application that deals with some data that cannot
    ever be written to a pagefile by the os without completely negating the
    entire purpose of the application.

    I'm curious if go has a package, or really anything, to prevent this.

    I realize that it might be possible to encrypt in-memory and decrypt only
    when necessary but I imagine that might not be totally reliable given that
    the garbage collector copies and destroys memory at its own will.
    Perhaps I am just being paranoid but one can never be too safe.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Bob Hemington at Aug 14, 2013 at 5:14 am
    Is this for some server software?

    I don't know of anyone who gives access to pagefiles or physical access to
    their servers and expects it to be secure. That sounds ridiculous to me.

    Bob
    On Tuesday, August 13, 2013 9:39:20 PM UTC-7, kyl...@gmail.com wrote:

    I see. I was really hoping for a pure go way. I'll see if I can use some c
    later on but for now I'll have to put a big warning label on it saying
    "DON'T LET ANYONE ACCESS YOUR PAGEFILE/GAIN PHYSICAL ACCESS TO YOUR
    SYSTEM/BE MALICIOUS TO YOUR PHYSICAL HARDWARE"
    On Tuesday, August 13, 2013 10:33:12 PM UTC-6, Bob Hemington wrote:

    As far as I know the problems you describe are correct (with GC doing
    what it wants too, and memory ending up in page files).

    I think the most feasible approach would be to find out how to do what
    you want in C, then use cgo.

    Bob
    On Tuesday, August 13, 2013 8:28:06 PM UTC-7, kyl...@gmail.com wrote:

    Hi, I'm working on an application that deals with some data that cannot
    ever be written to a pagefile by the os without completely negating the
    entire purpose of the application.

    I'm curious if go has a package, or really anything, to prevent this.

    I realize that it might be possible to encrypt in-memory and decrypt
    only when necessary but I imagine that might not be totally reliable given
    that the garbage collector copies and destroys memory at its own will.
    Perhaps I am just being paranoid but one can never be too safe.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kyleveb at Aug 14, 2013 at 5:33 am
    A password manager designed to choose the passwords for you.
    I'd love to be able to truthfully claim it implements security against
    attacks based on the memory of the system. Oh god, if someone gave me
    access to a physical server holding something important....
    On Tuesday, August 13, 2013 11:14:29 PM UTC-6, Bob Hemington wrote:

    Is this for some server software?

    I don't know of anyone who gives access to pagefiles or physical access to
    their servers and expects it to be secure. That sounds ridiculous to me.

    Bob
    On Tuesday, August 13, 2013 9:39:20 PM UTC-7, kyl...@gmail.com wrote:

    I see. I was really hoping for a pure go way. I'll see if I can use some
    c later on but for now I'll have to put a big warning label on it saying
    "DON'T LET ANYONE ACCESS YOUR PAGEFILE/GAIN PHYSICAL ACCESS TO YOUR
    SYSTEM/BE MALICIOUS TO YOUR PHYSICAL HARDWARE"
    On Tuesday, August 13, 2013 10:33:12 PM UTC-6, Bob Hemington wrote:

    As far as I know the problems you describe are correct (with GC doing
    what it wants too, and memory ending up in page files).

    I think the most feasible approach would be to find out how to do what
    you want in C, then use cgo.

    Bob
    On Tuesday, August 13, 2013 8:28:06 PM UTC-7, kyl...@gmail.com wrote:

    Hi, I'm working on an application that deals with some data that cannot
    ever be written to a pagefile by the os without completely negating the
    entire purpose of the application.

    I'm curious if go has a package, or really anything, to prevent this.

    I realize that it might be possible to encrypt in-memory and decrypt
    only when necessary but I imagine that might not be totally reliable given
    that the garbage collector copies and destroys memory at its own will.
    Perhaps I am just being paranoid but one can never be too safe.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jason at Aug 15, 2013 at 3:46 am
    A first blush it sounds ridiculous but it's really not.

    Hard drives die, servers get imaged, and storage/backup media unexpectedly
    walks off or otherwise isn't disposed of properly. What seems like a dead
    hard drive can sometimes be recovered by swapping off the logic board which
    is pretty simple. Anything that can be swapped to disk can walk off sight.

    Full disk encryption helps but then your machine can't reboot without a
    passphrase. Physical drive destruction is the only way to be sure but
    sometimes the guy who swaps out the drive doesn't follow process to the
    letter.
    On Tuesday, August 13, 2013 10:14:29 PM UTC-7, Bob Hemington wrote:

    Is this for some server software?

    I don't know of anyone who gives access to pagefiles or physical access to
    their servers and expects it to be secure. That sounds ridiculous to me.

    Bob
    On Tuesday, August 13, 2013 9:39:20 PM UTC-7, kyl...@gmail.com wrote:

    I see. I was really hoping for a pure go way. I'll see if I can use some
    c later on but for now I'll have to put a big warning label on it saying
    "DON'T LET ANYONE ACCESS YOUR PAGEFILE/GAIN PHYSICAL ACCESS TO YOUR
    SYSTEM/BE MALICIOUS TO YOUR PHYSICAL HARDWARE"
    On Tuesday, August 13, 2013 10:33:12 PM UTC-6, Bob Hemington wrote:

    As far as I know the problems you describe are correct (with GC doing
    what it wants too, and memory ending up in page files).

    I think the most feasible approach would be to find out how to do what
    you want in C, then use cgo.

    Bob
    On Tuesday, August 13, 2013 8:28:06 PM UTC-7, kyl...@gmail.com wrote:

    Hi, I'm working on an application that deals with some data that cannot
    ever be written to a pagefile by the os without completely negating the
    entire purpose of the application.

    I'm curious if go has a package, or really anything, to prevent this.

    I realize that it might be possible to encrypt in-memory and decrypt
    only when necessary but I imagine that might not be totally reliable given
    that the garbage collector copies and destroys memory at its own will.
    Perhaps I am just being paranoid but one can never be too safe.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Tamás Gulácsi at Aug 14, 2013 at 4:50 am
    You can pin pages of memory to not let the OS swap 'em by some syscalls. NOW the Go implementation uses a non-compacting GC thus the page with your array will not move. AFAIK

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kyleveb at Aug 14, 2013 at 5:31 am
    Excellent! ... could you kindly point me towards a link or a code sample?
    On Tuesday, August 13, 2013 10:50:35 PM UTC-6, Tamás Gulácsi wrote:

    You can pin pages of memory to not let the OS swap 'em by some syscalls.
    NOW the Go implementation uses a non-compacting GC thus the page with your
    array will not move. AFAIK
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dmitry Vyukov at Aug 14, 2013 at 7:53 am

    On Wed, Aug 14, 2013 at 7:28 AM, wrote:

    Hi, I'm working on an application that deals with some data that cannot
    ever be written to a pagefile by the os without completely negating the
    entire purpose of the application.

    I'm curious if go has a package, or really anything, to prevent this.

    I realize that it might be possible to encrypt in-memory and decrypt only
    when necessary but I imagine that might not be totally reliable given that
    the garbage collector copies and destroys memory at its own will.
    Perhaps I am just being paranoid but one can never be too safe

    Go GC does not copy memory, destroying should not cause problems in your
    case.

    You allocate some memory directly from OS, lock it in memory, and then
    construct some Go objects in there using unsafe. Then that memory won't be
    paged to swap file and GC won't touch it as well.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Maxim Khitrov at Aug 14, 2013 at 2:46 pm

    On Wed, Aug 14, 2013 at 3:53 AM, Dmitry Vyukov wrote:
    On Wed, Aug 14, 2013 at 7:28 AM, wrote:

    Hi, I'm working on an application that deals with some data that cannot
    ever be written to a pagefile by the os without completely negating the
    entire purpose of the application.

    I'm curious if go has a package, or really anything, to prevent this.

    I realize that it might be possible to encrypt in-memory and decrypt only
    when necessary but I imagine that might not be totally reliable given that
    the garbage collector copies and destroys memory at its own will.
    Perhaps I am just being paranoid but one can never be too safe


    Go GC does not copy memory, destroying should not cause problems in your
    case.

    You allocate some memory directly from OS, lock it in memory, and then
    construct some Go objects in there using unsafe. Then that memory won't be
    paged to swap file and GC won't touch it as well.
    I think these pages will still hit the disk if hibernation or Intel
    Rapid Start are used.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kyleveb at Aug 14, 2013 at 3:39 pm
    So, essentially, attempting to secure the data in memory is a lost cause
    given the complex factors present in the os and issues with physical
    security? Good to know!
    On Wednesday, August 14, 2013 8:45:33 AM UTC-6, Maxim Khitrov wrote:
    On Wed, Aug 14, 2013 at 3:53 AM, Dmitry Vyukov wrote:
    On Wed, Aug 14, 2013 at 7:28 AM, <kyl...@gmail.com <javascript:>>
    wrote:
    Hi, I'm working on an application that deals with some data that cannot
    ever be written to a pagefile by the os without completely negating the
    entire purpose of the application.

    I'm curious if go has a package, or really anything, to prevent this.

    I realize that it might be possible to encrypt in-memory and decrypt
    only
    when necessary but I imagine that might not be totally reliable given
    that
    the garbage collector copies and destroys memory at its own will.
    Perhaps I am just being paranoid but one can never be too safe


    Go GC does not copy memory, destroying should not cause problems in your
    case.

    You allocate some memory directly from OS, lock it in memory, and then
    construct some Go objects in there using unsafe. Then that memory won't be
    paged to swap file and GC won't touch it as well.
    I think these pages will still hit the disk if hibernation or Intel
    Rapid Start are used.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • André Moraes at Aug 14, 2013 at 3:56 pm
    You could clear the memory (fill with 0's) after you use it. This might
    reduce the chances of it going unencrypted into a pagefile or something
    similar.



    On Wed, Aug 14, 2013 at 12:39 PM, wrote:

    So, essentially, attempting to secure the data in memory is a lost cause
    given the complex factors present in the os and issues with physical
    security? Good to know!
    On Wednesday, August 14, 2013 8:45:33 AM UTC-6, Maxim Khitrov wrote:

    On Wed, Aug 14, 2013 at 3:53 AM, Dmitry Vyukov <dvy...@google.com>
    wrote:
    On Wed, Aug 14, 2013 at 7:28 AM, wrote:

    Hi, I'm working on an application that deals with some data that
    cannot
    ever be written to a pagefile by the os without completely negating
    the
    entire purpose of the application.

    I'm curious if go has a package, or really anything, to prevent this.

    I realize that it might be possible to encrypt in-memory and decrypt
    only
    when necessary but I imagine that might not be totally reliable given
    that
    the garbage collector copies and destroys memory at its own will.
    Perhaps I am just being paranoid but one can never be too safe


    Go GC does not copy memory, destroying should not cause problems in your
    case.

    You allocate some memory directly from OS, lock it in memory, and then
    construct some Go objects in there using unsafe. Then that memory won't be
    paged to swap file and GC won't touch it as well.
    I think these pages will still hit the disk if hibernation or Intel
    Rapid Start are used.
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.



    --
    André Moraes
    http://amoraes.info

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • F at Aug 15, 2013 at 3:46 am
    Hi,

    'Cryptography Engineering' recomends you generate a random string S,
    and store S and (key ^ S) in memory as far apart as possible.

    They do stress it's not 100% secure, but it might make attacks more
    difficult.

    http://www.amazon.com/Cryptography-Engineering-Principles-Practical-Applications/dp/0470474246

    Frederik
    On Wed, Aug 14, 2013 at 12:56:26PM -0300, André Moraes wrote:
    You could clear the memory (fill with 0's) after you use it. This might
    reduce the chances of it going unencrypted into a pagefile or something
    similar.



    On Wed, Aug 14, 2013 at 12:39 PM, wrote:

    So, essentially, attempting to secure the data in memory is a lost cause
    given the complex factors present in the os and issues with physical
    security? Good to know!
    On Wednesday, August 14, 2013 8:45:33 AM UTC-6, Maxim Khitrov wrote:

    On Wed, Aug 14, 2013 at 3:53 AM, Dmitry Vyukov <dvy...@google.com>
    wrote:
    On Wed, Aug 14, 2013 at 7:28 AM, wrote:

    Hi, I'm working on an application that deals with some data that
    cannot
    ever be written to a pagefile by the os without completely negating
    the
    entire purpose of the application.

    I'm curious if go has a package, or really anything, to prevent this.

    I realize that it might be possible to encrypt in-memory and decrypt
    only
    when necessary but I imagine that might not be totally reliable given
    that
    the garbage collector copies and destroys memory at its own will.
    Perhaps I am just being paranoid but one can never be too safe


    Go GC does not copy memory, destroying should not cause problems in your
    case.

    You allocate some memory directly from OS, lock it in memory, and then
    construct some Go objects in there using unsafe. Then that memory won't be
    paged to swap file and GC won't touch it as well.
    I think these pages will still hit the disk if hibernation or Intel
    Rapid Start are used.
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.



    --
    André Moraes
    http://amoraes.info

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kyleveb at Aug 16, 2013 at 10:02 pm
    That seems like a good idea. Something to implement on a later version
    though because that would require quite a bit of effort to integrate into
    the system.
    On Wednesday, August 14, 2013 9:59:33 AM UTC-6, f...@yay.im wrote:

    Hi,

    'Cryptography Engineering' recomends you generate a random string S,
    and store S and (key ^ S) in memory as far apart as possible.

    They do stress it's not 100% secure, but it might make attacks more
    difficult.


    http://www.amazon.com/Cryptography-Engineering-Principles-Practical-Applications/dp/0470474246

    Frederik
    On Wed, Aug 14, 2013 at 12:56:26PM -0300, Andr� Moraes wrote:
    You could clear the memory (fill with 0's) after you use it. This might
    reduce the chances of it going unencrypted into a pagefile or something
    similar.




    On Wed, Aug 14, 2013 at 12:39 PM, <kyl...@gmail.com <javascript:>>
    wrote:
    So, essentially, attempting to secure the data in memory is a lost
    cause
    given the complex factors present in the os and issues with physical
    security? Good to know!
    On Wednesday, August 14, 2013 8:45:33 AM UTC-6, Maxim Khitrov wrote:

    On Wed, Aug 14, 2013 at 3:53 AM, Dmitry Vyukov <dvy...@google.com>
    wrote:
    On Wed, Aug 14, 2013 at 7:28 AM, wrote:

    Hi, I'm working on an application that deals with some data that
    cannot
    ever be written to a pagefile by the os without completely
    negating
    the
    entire purpose of the application.

    I'm curious if go has a package, or really anything, to prevent
    this.
    I realize that it might be possible to encrypt in-memory and
    decrypt
    only
    when necessary but I imagine that might not be totally reliable
    given
    that
    the garbage collector copies and destroys memory at its own will.
    Perhaps I am just being paranoid but one can never be too safe


    Go GC does not copy memory, destroying should not cause problems in your
    case.

    You allocate some memory directly from OS, lock it in memory, and
    then
    construct some Go objects in there using unsafe. Then that memory
    won't
    be
    paged to swap file and GC won't touch it as well.
    I think these pages will still hit the disk if hibernation or Intel
    Rapid Start are used.
    --
    You received this message because you are subscribed to the Google
    Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an
    email to golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.



    --
    Andr� Moraes
    http://amoraes.info

    --
    You received this message because you are subscribed to the Google
    Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jens Alfke at Aug 16, 2013 at 11:43 pm

    On Wednesday, August 14, 2013 8:39:46 AM UTC-7, kyl...@gmail.com wrote:
    So, essentially, attempting to secure the data in memory is a lost cause
    given the complex factors present in the os and issues with physical
    security? Good to know!
    It's not a lost cause, but I'm pretty sure the APIs you'd need are entirely
    OS-dependent. I don't know Linux or Windows at that level, but on OS X
    (Darwin) what you want is called "wired memory". These are pages allocated
    directly out of RAM that are never swapped out. It's used for kernel-level
    services like device drivers and real-time audio, and unfortunately the
    system docs say it's not available to normal processes.

    I do know that the security frameworks on OS X use this type of memory to
    store passwords and private keys, for exactly the same reasons you want to.
    They may not be using wired memory exactly; there may be other Mach-level
    techniques for allocating address space with no persistent backing store.

    I have no doubt the same type of thing is available on Windows and Linux
    (and BSD?), partly because both those platforms also have secure
    key/password storage systems that require the same type of functionality.

    --Jens

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dmitry Vyukov at Aug 14, 2013 at 3:48 pm
    youre right

    On Wed, Aug 14, 2013 at 6:45 PM, Maxim Khitrov wrote:
    On Wed, Aug 14, 2013 at 3:53 AM, Dmitry Vyukov wrote:
    On Wed, Aug 14, 2013 at 7:28 AM, wrote:

    Hi, I'm working on an application that deals with some data that cannot
    ever be written to a pagefile by the os without completely negating the
    entire purpose of the application.

    I'm curious if go has a package, or really anything, to prevent this.

    I realize that it might be possible to encrypt in-memory and decrypt
    only
    when necessary but I imagine that might not be totally reliable given
    that
    the garbage collector copies and destroys memory at its own will.
    Perhaps I am just being paranoid but one can never be too safe


    Go GC does not copy memory, destroying should not cause problems in your
    case.

    You allocate some memory directly from OS, lock it in memory, and then
    construct some Go objects in there using unsafe. Then that memory won't be
    paged to swap file and GC won't touch it as well.
    I think these pages will still hit the disk if hibernation or Intel
    Rapid Start are used.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jan Mercl at Aug 14, 2013 at 8:00 am

    On Wed, Aug 14, 2013 at 5:28 AM, wrote:
    Hi, I'm working on an application that deals with some data that cannot ever
    be written to a pagefile by the os without completely negating the entire
    purpose of the application.
    I don't think this approach buys you anything. If someone can access
    your pagefile, then she can access all of the system's memory as well.
    (I'm not saying it's direct or easy ;-)

    -j

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Aug 14, 2013 at 6:01 pm
    That's only applicable if they're trying to access it from a running
    system. Not many systems intentionally sanitize their page/swap areas on
    shutdown. There may be other ways to access swap contents in a running
    system.
    On Wednesday, August 14, 2013 1:59:56 AM UTC-6, Jan Mercl wrote:
    On Wed, Aug 14, 2013 at 5:28 AM, <kyl...@gmail.com <javascript:>> wrote:
    Hi, I'm working on an application that deals with some data that cannot ever
    be written to a pagefile by the os without completely negating the entire
    purpose of the application.
    I don't think this approach buys you anything. If someone can access
    your pagefile, then she can access all of the system's memory as well.
    (I'm not saying it's direct or easy ;-)

    -j
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Alexandre Fiori at Aug 15, 2013 at 12:26 am
    What about http://golang.org/pkg/syscall/#Mlock

    See mlock(2) for details.
    On Tuesday, August 13, 2013 11:28:06 PM UTC-4, kyl...@gmail.com wrote:

    Hi, I'm working on an application that deals with some data that cannot
    ever be written to a pagefile by the os without completely negating the
    entire purpose of the application.

    I'm curious if go has a package, or really anything, to prevent this.

    I realize that it might be possible to encrypt in-memory and decrypt only
    when necessary but I imagine that might not be totally reliable given that
    the garbage collector copies and destroys memory at its own will.
    Perhaps I am just being paranoid but one can never be too safe.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • John Nagle at Aug 15, 2013 at 3:56 am

    On 8/13/2013 8:28 PM, kyleveb@gmail.com wrote:
    Hi, I'm working on an application that deals with some data that cannot
    ever be written to a pagefile by the os without completely negating the
    entire purpose of the application.
         Are you running Linux? Configure the machine without swap space.
    You might need more RAM.

         John Nagle

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Alexandre Fiori at Aug 16, 2013 at 12:28 am
    You don't have to not have swap. There's mlock(2) for that.
    On Wednesday, August 14, 2013 11:55:50 PM UTC-4, John Nagle wrote:
    On 8/13/2013 8:28 PM, kyl...@gmail.com <javascript:> wrote:
    Hi, I'm working on an application that deals with some data that cannot
    ever be written to a pagefile by the os without completely negating the
    entire purpose of the application.
    Are you running Linux? Configure the machine without swap space.
    You might need more RAM.

    John Nagle
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kyleveb at Aug 16, 2013 at 10:00 pm
    That wouldn't be an option, the application is supposed to be linux-windows
    compatible and shouldn't require users to mess with their system because of
    the difficulty to acquire users that would create
    On Wednesday, August 14, 2013 9:55:50 PM UTC-6, John Nagle wrote:
    On 8/13/2013 8:28 PM, kyl...@gmail.com <javascript:> wrote:
    Hi, I'm working on an application that deals with some data that cannot
    ever be written to a pagefile by the os without completely negating the
    entire purpose of the application.
    Are you running Linux? Configure the machine without swap space.
    You might need more RAM.

    John Nagle
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedAug 14, '13 at 3:28a
activeAug 16, '13 at 11:43p
posts22
users13
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase