Live data from Hacker News

We hacked Gemini's Python sandbox and leaked its source code (at least some)

landh.tech

121–130 of 151 posts

Re: We hacked Gemini's Python sandbox and leaked its source code (at least some)

#121
post #73

That's the system I work on! Please feel free to ask any questions. All opinions are my own and do not represent those of my employer.

I imagine you need to make and destroy sandboxed environments quite often. How fast does your code create a sandboxed environment? Do you make the environments on demand or do you make them preemptively so that one is ready to go the moment that it is needed? If you make them on demand, have you tested ZFS snapshots to see if it can be done even faster using zfs clone?

What’s ZFS? That doesn’t sound like a Google internal tool I’ve ever heard of.

Re: We hacked Gemini's Python sandbox and leaked its source code (at least some)

#122
post #73

Earlier quoted context omitted.

I imagine you need to make and destroy sandboxed environments quite often. How fast does your code create a sandboxed environment? Do you make the environments on demand or do you make them preemptively so that one is ready to go the moment that it is needed? If you make them on demand, have you tested ZFS snapshots to see if it can be done even faster using zfs clone?

What’s ZFS? That doesn’t sound like a Google internal tool I’ve ever heard of.

Oh boy. Get ready for the zealots

Re: We hacked Gemini's Python sandbox and leaked its source code (at least some)

#123
post #73

Earlier quoted context omitted.

I imagine you need to make and destroy sandboxed environments quite often. How fast does your code create a sandboxed environment? Do you make the environments on demand or do you make them preemptively so that one is ready to go the moment that it is needed? If you make them on demand, have you tested ZFS snapshots to see if it can be done even faster using zfs clone?

What’s ZFS? That doesn’t sound like a Google internal tool I’ve ever heard of.

https://en.wikipedia.org/wiki/ZFS

It's a filesystem, to put it simply.

Re: We hacked Gemini's Python sandbox and leaked its source code (at least some)

#124

> resulting in the unintended inclusion of highly confidential internal protos in the wild I don't think they're all that confidential if they're all on github: https://github.com/ezequielpereira/GAE-RCE/tree/master/proto...

I mean, those were also disclosed via a vulnerability.

But it still means they aren't guilty of leaking/disclosing them.

It's not a valid point of criticism. The escape did not in fact "result" in the leak of confidential photos. That already happened somewhere else. This only resulted in the republishing of something already public.

Or another way, it's not merely that they were already public elsewhere, the imortant point is that the photos were not given to the ai in confidence, and so re-publishing them did not violate a confidence, any more than say github did.

I'm no ai apologist btw. I say all of these ais are committing mass copyright violation a million times a second all day every day since years ago now.

Re: We hacked Gemini's Python sandbox and leaked its source code (at least some)

#125
post #73

Earlier quoted context omitted.

I imagine you need to make and destroy sandboxed environments quite often. How fast does your code create a sandboxed environment? Do you make the environments on demand or do you make them preemptively so that one is ready to go the moment that it is needed? If you make them on demand, have you tested ZFS snapshots to see if it can be done even faster using zfs clone?

I use ZFS, but isn't the situation the sandbox is in totally different? Why would it be optimal?

I believe they were referring to the use of ZFS snapshots for a Copy-on-Write type setup

Re: We hacked Gemini's Python sandbox and leaked its source code (at least some)

#127
post #73

Earlier quoted context omitted.

I imagine you need to make and destroy sandboxed environments quite often. How fast does your code create a sandboxed environment? Do you make the environments on demand or do you make them preemptively so that one is ready to go the moment that it is needed? If you make them on demand, have you tested ZFS snapshots to see if it can be done even faster using zfs clone?

I use ZFS, but isn't the situation the sandbox is in totally different? Why would it be optimal?

If you are making sandboxes, you need to put the files in place each time. With ZFS clones, you can keep referencing the same files repeatedly, so the amount of changes to memory needed to create an environment are minimized. Let’s say the sandbox is 1GB and each clone operation does less than 1MB of memory writes. Then you have a >1000x reduction in writing needed to make the environment.

Furthermore, ZFS ARC should treat each read operation of the same files as reading the same thing, while a sandbox made the traditional way would treat the files as unique, since they would be full copies of each other rather than references. ZFS on the other hand should only need to keep a single copy of the files cached for all environments. This reduces memory requirements dramatically. Unfortunately, the driver has double caching on mmap()’ed reads, but the duplication will only be on the actual files accessed and the copies will be from memory rather than disk. A modified driver (e.g. OSv style) would be able to eliminate the double caching for mmap’ed reads, but that is a future enhancement.

In any case, ZFS clones should have clear advantages over the more obvious way of extracting a tarball every time you need to make a new sandbox for a Python execution environment.

Re: We hacked Gemini's Python sandbox and leaked its source code (at least some)

#128
post #127

Earlier quoted context omitted.

I use ZFS, but isn't the situation the sandbox is in totally different? Why would it be optimal?

If you are making sandboxes, you need to put the files in place each time. With ZFS clones, you can keep referencing the same files repeatedly, so the amount of changes to memory needed to create an environment are minimized. Let’s say the sandbox is 1GB and each clone operation does less than 1MB of memory writes. Then you have a >1000x reduction in writing needed to make the environment. Furthermore, ZFS ARC should…

It's worth noting that if you go down a layer, LVM snapshots are filesystem-independent.

Re: We hacked Gemini's Python sandbox and leaked its source code (at least some)

#129
post #52

I've been using a similar trick to scrape the visible internal source code of ChatGPT Code Interpreter into a GitHub repository for a while now: https://github.com/simonw/scrape-openai-code-interpreter It's mostly useful for tracking what Python packages are available (and what versions): https://github.com/simonw/scrape-openai-code-interpreter/blo...

I just used this package list (and sandbox limitations) to synthesize a taxonomy of capabilities: https://gist.github.com/trbielec/a00a58fa97a232bef8984cc8d01...

Re: We hacked Gemini's Python sandbox and leaked its source code (at least some)

#130
post #128
post #127

Earlier quoted context omitted.

If you are making sandboxes, you need to put the files in place each time. With ZFS clones, you can keep referencing the same files repeatedly, so the amount of changes to memory needed to create an environment are minimized. Let’s say the sandbox is 1GB and each clone operation does less than 1MB of memory writes. Then you have a >1000x reduction in writing needed to make the environment. Furthermore, ZFS ARC should…

It's worth noting that if you go down a layer, LVM snapshots are filesystem-independent.

[deleted]
Post reply on HN