Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory layout and vulnerability to side-channel attacks #20

Closed
alveko opened this issue May 3, 2018 · 1 comment
Closed

Memory layout and vulnerability to side-channel attacks #20

alveko opened this issue May 3, 2018 · 1 comment

Comments

@alveko
Copy link

alveko commented May 3, 2018

Q1: Is the memory layout of the guest same as if it runs directly on the host kernel? Specifically, if the underlying host kernel maps all physical memory to virtual address space of each process (the way which made Meltdown possible), will it preserve such mapping in the gVisor container?

Q2: Assuming the underlying host kernel and CPU is vulnerable side-channel attacks (same as or similar to Meltdown/Spectre), would one guest in one gVisor container be able to attack another guest in another gVisor container on the same host? and why so?

@amscanne
Copy link
Contributor

Sorry, somehow I think this issue went unnoticed!

Q1: For the KVM platform, only host user space spaces are available to the guest, so Meltdown would not apply. For ptrace, yes, you still have the upper half (but you also now have KPTI).

Q2: I'm sure it's theoretically possible. Not sure how easy or practical. Applies the same way to different VMs on the same host. (If you can probe cache timing, you can exploit Spectre.) Heck, apparently some clever folks have successfully exploited Spectre by probing cache timings with network packets.

Feel free to reopen for follow-up.

amscanne pushed a commit to amscanne/gvisor that referenced this issue May 6, 2020
When ContainerD v1.2.4 creates a task, it may pass a *runctypes.CreateOptions in the request options field. This currently causes the gvisor-containerd-shim to reject the request.

This PR allows the shim to handle requests with creation options set, and also slightly improves the error message so future failures of this kind are easier to localize to the shim.

Fixes google#19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants