New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
You can't really emulate those, unless you stole AMD's private keys somehow.
https://github.com/virtee/snpguest
You can get the cheapest plan @onidel and play with it
You mean that thing here, i guess?
Looks impressive for sure and i wouldn't claim to understand a portion of it but i also wouldn't trust it before i spend a couple months trying to subvert the scheme by having the guest getting an AOK for another guest
The problem with this is that the guest has no access to the actual hardware and needs to believe whatever it's getting while everything it does is fully observable from the hosts side. I mean, sure it could encrypt something with a public key supplied by AMD but then the host already knows the plaintext anyways. It can send something out to be signed but whatever it sends can be swapped around and mangled however the host pleases.
Admittedly grabbing some kind of plaintext at the exact time it gets prepared by some application on the client would be very far from trivial. It's a very fundamental problem in general and who knows maybe some genius has solved it but i don't see how any kind of guarantee would work without the guest being able to establish some kind of secure communications channel with literally anything.
No. This is hardware attestation. Google's Pixel devices have a similar verified-boot.
No. You cannot access the guest memory from the host. So something like dumping
the quest memory using qemu pmemsave or virsh dump won't fly.
No. The CPU does, but the host OS cannot access that ring. Consider it like another ring
below the host kernel. A TPM chip will be a good example. No trust involved. No plaintext.
That's different because there's no hostile layer between the software and the actual hardware.
It can if it had lied about the encryption in the first place which this is about after all.
The guest has no (direct) access to the CPU. It can try to execute opcodes which the host is free to emulate however it pleases.
That's the basic problem here. The guest can say "hello tpm please sign ABC" but the host makes it into "hello tpm please sign 123". The guest won't have any control or knowledge about that. The whole world guest lives in is 100% controlled by the host. There's nothing that could be used as an unique identifier.
Edit: Well, maybe you could use the whole state as in the complete RAM dump as kind of an ID since replicating that elsewhere you basically put that machine into an at least similar state, which would at least massively complicate using it as dummy. In the end you probably just need matching memory regions though.
They are cryptographically signed. The attestation tool has pinned public keys of the AMD CPU, each CPU is fused with it's own set of keys. This completely eliminates the host's ability to interact as any sort of man in the middle, because you attest the parts where the
host kernel has no access to. This would be impossible to emulate without some sort of leak of those keys from AMD.
In a traditional environment, you are right, but not with SEV-SNP.
Yeah, that sounds great but it leaves the big question open: How do you attest those parts? Presumably using the convoluted scheme from the slide above but the basic problem is: How to get a guarantee in an environment where you can't guarantee anything?
The guest can't establish any kind of secret since the (lying) host has access to anything the guest has access to and it also can't communicate with the hardware without the host being free to mangle data as it sees fit, so whatever the client sends off for signing/signature checking can transform into anything or nothing.
In theory the guest would somehow need to make sure that wouldever it tried communicating with the hardware was actually transmitted as is but even if it had a chance to do so that check would again be under full control of the host.
Once such basic guarantees are established it gets pretty simple. I'm not challenging that but the initial part needs a small wonder to work out (there's a lot of people smarter than me so i wouldn't be surprised if said wonder existed but i personally don't see how it would be possible).
Obviously interfering with actual applications from the host side of things is extremely complicated since it needs to either keep track of a ton of moving parts inside the running OS or at least know where to grab the needed information (there's nothing like a PID as far as the CPU is concerned after all), so emulating some kind of specific opcodes is pretty much the simple part.
Taking such an ability for granted there wouldn't really need to be an actual subversion of the attestation scheme though. All it takes is the ability to detect the check tool and manipulate execution to make a negative result into a positive. Given that would be way to specific to a certain piece of software that could also morph massively just by changing compiler settings that's not worth much though. Looking at it this way i feel that the biggest protection this scheme has lies in the complexities of messing with actual applications inside the VM. If those wouldn't exist it would be pointless no matter what.
Edit: I know, i know. I'm basically doubting big mighty tech company here. Feel free to disregard my skepticism on that basis
Edit2: If i were to attack this i'd probably try to produce some code that's able to hook into the basic disk io api of the most common kernels from the host side of things. Once that works it's all about detecting AMDs public key being read and replacing it with one under the host's control (theoretically constantly monitoring memory for AMDs key would be a more general approach but likely also pretty bad performance wise). Voila host is free to sign all communication at will. That's probably the vector involving the least amount of intimate knowledge about the OS being run and the amount of kernels commonly found in the wild is probably not that big. With a little luck the io api also has some kind of signature/reference that makes a broader scan based approach possible instead of having to hardcode kernels.
Very trustworthy mechanism. I ticked the box, my firewall must be protecting me now.
It's time to say goodbye to OVZ!
Network is fast my man!
Probably I will not popular with this answer, but yes, I keep them (I have only few OVZ based VM - but all of them rock solid, reliable). I try to protect them with different solutions (firewall, etc) I know, it's not protect from everything. And I hope, the affected providers will be provide a migration solution (with same, similar conditions, like pricing) when OVZ support is EOL officially (December 2026?). The mentioned VM's is from old, reliable providers, with very good pricing and conditions (what I can't let "fly away").
Hi,
basically easy. Simply follow this checklist:
[ ] (data) safety not important?
[ ] all software you need run's there?
if both is yes, then stay.
If not, then not.
For free or for a fee, it doesn't matter, I say you will not be able to do it in either case, and with absolute certainty I say you will not be able to do it profitably.
If you insist in doing it it will be for a loss,
If you truly need confidential computing you should use your own fully audited hardware not rely on Azure, GCP or AWS.
EDIT: And host in your own datacenter, no colocation.
Wait a minute, wouldn't that imply hiring and relying on many people? People you don't know that well? Or maybe you know them well and you know you can't trust them. No so confidential after all, right?
Confidential computing, unless you're doing it offline, in an environment fully controled by you, you'll be better forgetting about it,
Tell it to AWS GovCloud customers and Fortune 500 companies who use those services.
Do you think every 1+ billion dollar tech company has it's own datacenter? Yet they do
perfectly fine on a shitty public cloud, sometimes without getting hacked. Crazy I know.
I guess you're right, our data is perfectly safe with them, we can trust them. And I bet they never leak or get hacked.
Wait a minute...
They do perfectly fine because when they err someone else pays for it, never them.
That's all there is to it really.
And "without getting hacked"?????
Who told you that?
thanks for the inputs, although i dont quite understand the middle replies on security, hacking, key, encryption etc.
i decide not to renew $7 deal because for example $7->$10 racknerd, i can get 25gb vs 10gb (still 1 core and 1 gb ram though)
but my main reason, is i may convert my old school /var/www/html deployment(s) to docker containers and i used to have issue few years back with docker with certain provider's openvz but kvm vps always work.
well .. i spent the last couple of hours with the help of various AI, built a single docker compose file that contains nginx, mariadb, php-fpm containers
i manage to migrate 1 non-docker app over. so the idea is all my old school /var/www/ deployment(s) will be serviced by these 3 containers but each with their own appX.nginx.conf .. then all fronted by my already deployed nginx-proxy with letsencrypt
best of both world because i still get to keep lemp/apps/app1, lemp/apps/app2 structure sort of like /var/www/html/(apps) at old vps
Wanna know what launches
/bin/login? It's agetty.I did this years ago as part of training so I don't remember exactly what I did (this was before systemd was popular, for context), but if you can control the memory of agetty, you can absolutely have it spawn a root shell for you.
Not 100% true. Only some instructions can trap to a #vmexit. This obviously includes privileged instructions, instructions accessing certain memory regions, and some instructions like CPUID. But not every instruction can be trapped.
This doesn't matter what launches what, /bin/login itself doesn't verify the credentials,
PAM does. So you cannot memory patch it and get root, doesn't work like that.
The credential verification happens downstream in separate process memory.
Since specifically agetty was mentioned, I call bs.
Verification happens in the same process memory as PAM uses libraries, so it'll exist in the same address space as the login process. But by modifying memory,
/bin/logindoesn't even get spawned, so it can't even do verification. Although I suppose you could also hijack PAM just by changing the return code to success.What happens is you put in some wrong password. The login process checks it and fails, returning failure to agetty. Then agetty, rather than launching another login process, just launches a shell because its memory has been modified. No need to tamper with
/bin/loginitself or the actual verification.Yeah, like i said initially emulating random instructions might need to rely on software emulation (including all the penalties that come with it). Single stepping might also be an option but i'm not sure if that would gain a whole lot in comparison to just going straight to software.
It's kind of hard to say if it would be needed here. Hooking into kernel API can probably be done with some creative breaks on memory access and simply overwriting entry points. Monitoring memory for a more generic approach basically just means making everything of interest into an MMIO region as far as qemu is concerned (likely at the cost of a non-trivial performance penalty though).
From there on i don't really know enough about the process to make a guess how feasible it would be to avoid software emulation. Actually manipulating running processes inside the guest is a massive task in any case and also not really very desirable if the goal is to fool the concept as a whole and not just some specific check tool.
The most common "in the wild" technique that makes things easier is to mess with the IDT. Its location is easy to find by scanning the memory for anything that looks like the IDT and checking if the pointers actually point to executable code that ends in an IRET. That's how most DMA attacks are (or were) pulled off. You can have code executed reliably and you don't have to worry about being in some unpredictable execution context.
That way there's no need to mess with KVM trapping and emulating instructions.
That makes a lot of sense. If running some code inside the guest is the main goal that's probably pretty straight forward. It's kind of a long way from there to having executable X print 123 instead of ABC though (stupid example but you probably get what i mean). The more low level you stay the better your chances are to actually get a desirable result before going insane
In the end straight up manipulating specific executables probably won't be feasible unless you basically know the relevant code parts byte-by-byte beforehand (not like that would make it easy but at least you'd know what to do once you somehow found your target), which likely makes it kinda pointless as a general approach (basically every second compiler setting instantly kills it). Chances are manipulation would need to keep to somewhat well defined interfaces like interrupts, kernel API and so on.
Once you have achieved fully arbitrary code execution in the kernel, the rest is pretty easy. You can do anything. You could hook individual syscalls and tamper with their behavior for a specific binary, for example. You can forcibly load specific libraries or change the return values of individual functions. Just look at all the magic you can do with tracepoints and uprobes. Or if you're lazy, you could just open a reverse root shell and do everything with bash.
Look at the type of magic you can do with utilities like
bpftraceon userspace processes. Want to know the exact return value of a specific function from a specific library but you only want that return value if the previously called function's second argument was non-null and its third argument is a pointer to a string that starts with a specific prefix? You can do that, no compiler instrumentation needed. The kernel has the ability to do that, so you can do it from within the kernel.No
That's where remote attestation comes in. It does work (i.e. prevents monitoring or tampering by the host, even if the host has root and has full control over the kernel running KVM and the QEMU process itself), but as is usual, physical access allows you to bypass the protection and inspect guest state.
Under ideal circumstances that might actually be the case but even then things stop being so easy once your target is a specific peace of logic in an executable whose exact version or binary representation you don't know. Even outside of that you've already moved from a simple i'm able to deduct RIP to knowing a lot about the running system. Might not be that hard once you've found the kernel entry point but i'd still expect it to be a little hairy and something like spawning shells isn't really helpful for subverting a certain calculation as soon as it runs. You could obviously try to replace all relevant binaries with /bin/true while hoping to get there before they'll run but that hardly seems practical.
Oh, there's certainly a lot of things that are possible. Especially once locate some neat and tidy table telling you were functions are you conveniently also know the interfaces of but in the end those are things you'll get to mull over once you get to work, which i'm not. I've written my fair share of injections, in memory patches and all that voodoo. Once you know where to strike it's rather simple in one way or the other
Think about it for a second and realize that everything you said before basically tells a different story. Sure it will work but given the guest has zero hope to expect whatever it does produces a truthful result in some expected way there can't be any reliable way of verifying anything. Whatever the guest tries to do to verify the presence of those protections can be swapped behind its back (maybe at a massive cost but it still can). Sure, maybe there is some magic trick to get around that basic logic but unless i know what that specific trick is it just seems like defying gravity to me.
Edit: The only way i see how this could get anywhere is by encrypting /boot (kernel alone would probably be kinda sufficient but also leak a ton of information) in a way that makes it only possible to be read/executed by TPM likely in combination with full disk encryption to prevent tampering on that front (there can't be any point in time where it is possible to mess with execution - or the kernel image being loaded since that's practically the same result - before the kernel is in a running and fully protected state).
Even in that case replicating enough of that /boot for the user not realize that what they are using to boot their system isn't really their own install but a hostile clone would break it wide open again (since it just skips the TPM part). Obviously that assumes quite a bit of knowledge on the by definition unknown system and likely a good bit of carelessness on the part of the user but the basic theory still stands (even if quite magical-Christmas-landish at that point).