Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VMScape and why Xen dodged it

virtualize.sh

Post reply on HN
Print view View original

11–20 of 40 posts

Re: VMScape and why Xen dodged it

#11

Post by exe34 »

duskwuff wrote: post #7
remix2000 wrote: post #6

Earlier quoted context omitted.

It's not necessarily a sign of AI slop — could be just proper typography! :3

It's not the em dash, but the negative parallelism ("not X, but Y"). This is a pattern which some LLMs really like using. I've seen some LLM-generated texts which used it in literally every sentence. (The irony of opening with this pattern is not lost on me.) As an aside, Wikipedia has a fascinating document identifying common "tells" for LLM-generated content: https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writ…

I have autism and I like using that kind of comparison when writing.

Re: VMScape and why Xen dodged it

#12

Post by [deleted] »

bayesnet wrote: post #5

While it’s interesting that Dom0 avoids Spectre-style branch prediction attacks it’s not clear from TFA exactly why that is so. How does the architecture of the hypervisor avoid an attack that seems to be at the hardware level? From my limited understanding of Spectre and Meltdown, swapping from a monolithic to a microkernel wouldn’t mitigate an attack. The mitigations discussed in the VMscape paper [0] are hardware…

[deleted]

Re: VMScape and why Xen dodged it

#14

Post by eigenform »

Since everyone is upset about the lack of technical details in the article, I'll try:

The takeaway from that paper (imo, afaict) is that guest userspace can influence indirect predictor entries in KVM host userspace. I don't really know anything about Xen, but presumably it is unaffected because there is no Xen host userspace, just a tiny hypervisor running privileged code in the host context. With KVM, Linux userspace is still functional in the host context.

Presumably, the analogy to host kernel/userspace in KVM is dom0, but in Xen this is a guest VM. If cross-guest cases are mitigated in Xen (like in the case of KVM, see Table 2 in the paper), you'd expect that this attack just doesn't apply to Xen. Apart from there being no interesting host userspace, IBPB/STIBP might be enough to insulate other guests from influencing dom0. If you're already taking the hit of resetting the predictors when entering dom0, presumably you are not worried about this particular bug.

edit: Additional reading, see https://github.com/xen-project/xen/blob/master/xen/arch/x86/...

Re: VMScape and why Xen dodged it

#15

Post by barrkel »

duskwuff wrote: post #7
remix2000 wrote: post #6

Earlier quoted context omitted.

It's not necessarily a sign of AI slop — could be just proper typography! :3

It's not the em dash, but the negative parallelism ("not X, but Y"). This is a pattern which some LLMs really like using. I've seen some LLM-generated texts which used it in literally every sentence. (The irony of opening with this pattern is not lost on me.) As an aside, Wikipedia has a fascinating document identifying common "tells" for LLM-generated content: https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writ…

It's antithesis. And it's really overused by ChatGPT.

Re: VMScape and why Xen dodged it

#16

Post by csmantle »

bayesnet wrote: post #5

While it’s interesting that Dom0 avoids Spectre-style branch prediction attacks it’s not clear from TFA exactly why that is so. How does the architecture of the hypervisor avoid an attack that seems to be at the hardware level? From my limited understanding of Spectre and Meltdown, swapping from a monolithic to a microkernel wouldn’t mitigate an attack. The mitigations discussed in the VMscape paper [0] are hardware…

I think the author actually meant "Yes, vmscape can leak information on Xen, but only leaks from a miniature Dom0 process." Leaking from an small pool not being a security issue they seemed to consider.

Agreed on the point about hw-level mitigation. The leakage still exists. Containing it in a watertight box is quick and effective, and it does avoid extra overhead. But it doesn't patch the hole.

Re: VMScape and why Xen dodged it

#17

Post by snvzz »

The Xen "microkernel" is unfortunately bloated. seL4 is much smaller and runs VMM as an isolated unprivileged task.

VM exceptions are all handled by VMM. A VM escape would still be confined in VMM, which has no higher capabilities than the VM itself. Capabilities are enforced by the formally verified seL4.

Re: VMScape and why Xen dodged it

#18

Post by shippage »

duskwuff wrote: post #7
remix2000 wrote: post #6

Earlier quoted context omitted.

It's not necessarily a sign of AI slop — could be just proper typography! :3

It's not the em dash, but the negative parallelism ("not X, but Y"). This is a pattern which some LLMs really like using. I've seen some LLM-generated texts which used it in literally every sentence. (The irony of opening with this pattern is not lost on me.) As an aside, Wikipedia has a fascinating document identifying common "tells" for LLM-generated content: https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writ…

I'm also on the spectrum and like using various kinds of parallel construction, including antithesis.

I also tend to use a lot of em dashes. If I posted something I wrote in, say, 2010, I'd likely get a lot of comments about my writing absolutely, 100% being AI-written. I have posted old writing snippets in the past year and gotten this exact reaction.

I originally (two decades ago) started using em dashes, I think, because I also tend to go off on frequent tangents or want to add additional context, and at the beginning of the tangent, I'm not entirely sure how I'll phrase it. So, instead of figuring out the best punctuation at that moment (be that a parenthesis, a comma, or a semicolon for a list), I'll just type an em dash (easy on a Mac).

Then I don't go back and fix it afterward because I have too many thoughts and not enough time to express them. There are popular quotes about exactly this issue.

It's a kind of laziness in the form of my expression to give me more mental capacity to focus on the content. Alt 0151 and Alt 0150 are still burned into my memory from typing em dashes and en dashes so often on Windows.

I suppose I'll have to consider this my own punctuation mode collapse that RLHF is now forcing me to correct.

Re: VMScape and why Xen dodged it

#19

Post by AtlasBarfed »

So this requires the two VMs to be sharing execution on a core? Or perhaps a shared cache? Or would it work across VMs "pinned" to different CPUs?

It's weird to me that cloud hosts aren't absolutely swimming in cores now, but with Intel struggling and AMD somewhat resting on its laurels, which it stupidly did in the Hector Ruiz days, nothing is pushing the envelope. In 2010, fifteen years ago, we had 12 core CPUs.

In 2010 we had a billion or so transistors. In 2020, we had 50 billion. In 2010 we were at 28nm, now we're at 3nm.

We should have 100x the CPUs on die now or more. a thousand x86 cores, god knows how many Arms, and god knows how much you could do with hi-low core counts.

Anyway, what I'm getting at is all of these vulnerabilities across process execution or VM execution could be moot: if the processes were isolated to a core or set of cores, and the VM isolated to its own dedicated branch predictors in its own cores. Then go ahead and do whatever tricks you want. Obviously you don't want hyper-threading.

Re: VMScape and why Xen dodged it

#20

Post by sim7c00 »

mikewarot wrote: post #10
bayesnet wrote: post #5

While it’s interesting that Dom0 avoids Spectre-style branch prediction attacks it’s not clear from TFA exactly why that is so. How does the architecture of the hypervisor avoid an attack that seems to be at the hardware level? From my limited understanding of Spectre and Meltdown, swapping from a monolithic to a microkernel wouldn’t mitigate an attack. The mitigations discussed in the VMscape paper [0] are hardware…

I think it might be translation from French instead of LLM usage. While Microkernels are great for overall security, it's also not obvious to me how it helped in this case.

it might be as simple as more rigid context transfers flushing caches. there are a lot of guesses on here now. itd be great if people stopped using may or might and looked in the code. everyone's hopping on the lack of context and adding guesses. thats not helpful
Post reply on HN