All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Free P2P GPU sharing — what would stop you using this over Vast/RunPod?
Not an offer, nothing to sell — this is free and there's no platform. I genuinely want the objections.
The idea: one script on a box with Docker and a GPU prints a link. Whoever opens it lands in a terminal on that machine, right in their browser. No account for either side, no listings, no fees, no middleman.
It's not trying to beat Vast or RunPod at renting from strangers — they're great at that. It covers the case they structurally can't: getting a specific person onto a specific machine, right now. A marketplace needs liquidity; this works with two people and one box.
https://runsnack.com — install scripts are on GitHub (Apache 2.0), so you can read the docker run flags before running anything. The agent inside the container is closed source.
What I'm asking: you've all got idle hardware and strong opinions about isolation. What kills this for you? Docker not being a VM? No escrow? Closed agent? Something I haven't thought of?
Genuinely want the harsh version. Thanks!
Comments
Plenty of research showing that direct access to a GPU allows you to takeover anything else running on that GPU. No isolation without vGPU.
nah docker aint even the main issue for me, closed source agent is the actual dealbreaker. i can read the install script all day but the thing actually executing inside the container when some stranger sends commands is a black box, cant verify its not doing anything sketchy beyond the terminal session, no syscall filtering i can check, nothing. @forest already mentioned the problem. raw gpu passthrough with no mig/vgpu partitioning means shared gpu memory space, theres actual research on reading leftover vram from other processes after context switches. cuda isolation aint some hardware enforced thing like sr-iov, its basically just hoping nobody goes digging through stale memory. docker sharing the host kernel is its own thing too, one kernel cve or a misconfigured cap and its not container access anymore its host access. vast/runpod at minimum give you a real vm with its own kernel. would need gvisor or kata instead of raw docker, mig based gpu partitioning instead of
--gpus all, and the agent actually open sourced so ppl can see whats running not just the wrapper script around it.yeah no mig/vgpu means shared gpu memory space and cuda doesnt actually enforce isolation the way ppl assume, its basically relying on processes not going out of their way to read stale vram instead of real hardware separation like sr-iov gives u on nics. op should just say straight up if this is bare
--gpusall passthrough with no mig config, cuz if so thats a data leak risk even with zero escape happening, just from sharing gpu context with some random strangers workloadEDIT
that cuda memory isolation issue is an nvidia thing specifically. if op's stack is nvidia gpus the whole no-mig shared vram context leak risk applies straight up, cuda doesnt hardware enforce isolation without mig/vgpu. if its amd tho, different stack entirely, rocm/hip instead of cuda, and amd's got their own equivalent problem, sr-iov based gpu virtualization exists on some instinct cards (mi series) but consumer/prosumer amd gpus dont really have a mig equivalent at all, so raw passthrough on amd without proper sr-iov partitioning is arguably even less isolated since theres no partitioning option to fall back on in the first place. op should just clarify which gpu vendor this is actually targeting cuz the isolation story is completely different depending on nvidia vs amd, and if its meant to be vendor agnostic that just doubles the isolation gaps since youd need to solve both separately
if apple silicon is in scope thats a different mess, metal doesnt even have a mig/sr-iov equivalent, gpu passthrough to containers on mac is basically not a real thing since docker runs through a linux vm under the hood anyway. igpus (intel/amd) are honestly worse for this ngl, shared memory with the cpu means ur not just sharing vram context ur potentially sharing system memory the igpu touches directly. va-api/quicksync passthrough has zero mig equivalent either.
if somethings wrong here let me know, im not that big of a nerd on this stuff
I think Nvidia and AMD are equally vulnerable when not using SR-IOV-based isolation, so it's not unique to Nvidia (besides CUDA itself being an Nvidia product). No GPU has any kind of native isolation between running kernels.
DMAR is used to isolate that so that's not an issue. The iGPU could not touch system memory that's not allocated as VRAM. That doesn't mean it's 100% safe though, because the GPU driver has a huge attack surface area and the GPU hardware -> GPU driver interface is not generally considered a privilege boundary.
okkey so that means sr-iov gives u iommu level pci function isolation. without it gpu context switching just relies on the scheduler, no guaranteed vram/register clearing between contexts so stale data from a previous context can just sit there for the next one to read. mig/vgpu gives some of that isolation without full sr-iov but its still software enforced not hardware enforced so a driver bug or misconfig can still leak across.
igpu thing yeah my bad missed dmar. dmar isolates that so igpu cant touch system memory outside vram but gpu-to-driver interface isnt a privilege boundary drivers run in kernel/ring0 with a massive attack surface. side channel timing on shared execution units malformed command buffer submission triggering exec gpu firmware bugs none of that gets touched by dmar or sr-iov those only handle memory access isolation not the actual command/firmware execution path. so intel gen graphics amd gcn/rdna apples gpu firmware all share this same driver is the real boundary problem regardless of vendor
The fact that it's AI slop along with your entire post
Not just to read but to modify. Each kernel can access the entire VRAM.
kernels arent normally able to read/write across the entire vram just by existing, gpu driver sets up separate virtual address spaces per context same idea as cpu process isolation, so a kernel cant just touch another processes live memory under normal operation. whats real tho is freed vram isnt reliably zeroed before reuse so stale data leaking into a new allocation is a legit issue, and without sr-iov/mig theres no hardware enforced boundary so a driver bug or scheduler/tlb level exploit can still break isolation. so its less "any kernel can read/write all vram by default" and more "the isolation thats there is software enforced and driver dependent, not hardware guaranteed," which still ends up dangerous just for a slightly different reason than stated
That's only at the CUDA level. The low-level machine code can get all of the VRAM, but it takes some tricks (there are some research papers about finding out the right addresses to use, IIRC). You just can't write CUDA code that emits the machine code sequences needed. But you could write it manually. Takes some reverse engineering since Nvidia doesn't publish any low-level assembler (and what they call their "assembler" is actually not).
The existing isolation isn't software-enforced, it's hardware enforced, but it's not designed for security, more designed to prevent a buggy kernel from causing everything else to go haywire.
Sounds like a job for static analyzer
@forest @itzsenu — thanks, most useful feedback I've had on this.
Straight answer: yes, bare --gpus all, no MIG. And on consumer hardware there's nothing to partition with in the first place — MIG and vGPU only exist on datacenter parts, so for a 4090 or a Jetson this isn't a config I've skipped, it's a capablity that doesn't exist. Zeroing VRAM between sessions would narrow the window but wouldn't change the threat model, since as you said the isolation is software-enforced and the driver interface isn't a privilege boundary.
So I'm not going to claim I can fix it. What I can do is stop under- describing it — the site says "Docker is a sandbox, not a hypervisor" and that's the wrong caveat to lead with. The GPU boundary is the weaker one so i'm updating that.
On the closed agent: fair, and it's the objection I get everywhere.
ok yeah checked more into this and youre right. found papers on it (Guardian/G-Safe multi-tenant gpu sharing research) that literally say the isolation cuda gives you at the api level doesnt exist at the actual GPU context level, quote is basically "application host memory is protected because processes are separate, this is not the case for device code which runs on the same gpu context." so normal cuda api calls stay in their lane cuz the runtime/driver enforces boundaries for you, but if youre writing raw ptx/sass instead of letting nvcc generate it normally, that enforcement isnt a hardware wall, its just the compiler not generating out of bounds pointers for you. also found the "tunnels for bootlegging" usenix/ccs paper specifically about reverse engineering gpu tlbs to break mig isolation guarantees, so even hardware level partitioning has had documented bypass research. so yeah my earlier point was wrong framing it as "kernels cant touch other vram under normal operation" full stop, more accurate is cuda level tooling wont let you but the actual hardware/driver boundary underneath isnt enforced the same way cpu process isolation is unless somethings like mig or a system like guardian is specifically bolted on top.
also checked the sass assembler claim specifically since thats a real verifiable detail and youre dead on there too. nvidia genuinely doesnt ship a real sass assembler, only nvdisasm and cuobjdump which are disassemblers not assemblers. ptxas is officially called an "assembler" but its actually compiling ptx down to sass, not assembling raw sass into machine code, theres a real difference there. all the actual sass level tooling (maxas, asfermi, cuassembler, turingas) are unofficial community reverse engineered projects, one guy at a time figuring out opcode encodings generation by generation since nvidia publishes basically nothing beyond a mnemonic list with no semantics. so writing raw sass by hand to touch memory outside what cuda/ptxas would ever generate is a real documented thing people do, just requires reverse engineering the isa yourself since theres no official spec.
the hardware vs software enforced distinction also tracks with that context, if the isolation boundary is baked into how the mmu/context switch hardware works rather than something the driver software checks, makes sense its there to stop a buggy kernel from corrupting gpu state rather than as an actual security boundary against someone deliberately trying to break out. different design goal entirely, stability vs adversarial isolation, and thats exactly why hand crafted sass bypassing normal cuda generated access patterns can get around it. appreciate you laying out the mechanism
That's why you also need CC (Confidential Compute) enabled alongside vGPU. But even that's often not enough.
Btw, why do your messages simultaneously scream LLM and not LLM at the same time?
I mean it's obviously pure LLM output but do you manually edit it? Or just have the prompt include "use all lowercase, use text-speak such as cuz rather than because"? I'm actually curious.
https://lowendtalk.com/discussion/comment/4840452/#Comment_4840452
that's why. still haven't gotten rid of it. you can see correct uppercase lowercase when I typed using my phone
h100 h200 blackwell cc mode encrypts vram and blocks host hypervisor direct access. consumer cards like 4090s dont have cc silicon tho so doesnt even apply here. needs intel tdx or amd sev-snp on host cpu paired with it too, cant run standalone. side channels still work even with cc on, power timing leaks and nvlink covert channels
Are you sure they don't? I'd expect they would but it would just be disabled in firmware or fused-out with an OTP.
But even with CC on, if you have physical access... https://tee.fail
Just a quick remark: updated the site and added a SECURITY.md documenting the VRAM situation, plus a GPU reset between sessions as the practical mitigation for consumer cards — thanks both, this was genuinely useful.