From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751605AbcEJMEm (ORCPT ); Tue, 10 May 2016 08:04:42 -0400 Received: from mail.skyhub.de ([78.46.96.112]:56896 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750741AbcEJMEj (ORCPT ); Tue, 10 May 2016 08:04:39 -0400 Date: Tue, 10 May 2016 14:04:34 +0200 From: Borislav Petkov To: Paolo Bonzini Cc: Tom Lendacky , Andy Lutomirski , linux-arch , "linux-efi@vger.kernel.org" , kvm list , "linux-doc@vger.kernel.org" , X86 ML , "linux-kernel@vger.kernel.org" , kasan-dev , "linux-mm@kvack.org" , iommu@lists.linux-foundation.org, Radim =?utf-8?B?S3LEjW3DocWZ?= , Arnd Bergmann , Jonathan Corbet , Matt Fleming , Joerg Roedel , Konrad Rzeszutek Wilk , Ingo Molnar , "H. Peter Anvin" , Andrey Ryabinin , Alexander Potapenko , Thomas Gleixner , Dmitry Vyukov Subject: Re: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD) Message-ID: <20160510120434.GC16752@pd.tnic> References: <20160426225553.13567.19459.stgit@tlendack-t1.amdoffice.net> <57211CAB.9040902@amd.com> <5730A91E.6040601@redhat.com> <5730FC33.2060804@amd.com> <5731C4B7.9000209@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5731C4B7.9000209@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 10, 2016 at 01:23:35PM +0200, Paolo Bonzini wrote: > It can send plaintext packets that will be stored encrypted in memory. > (Of course the hypervisor can do that too if it has access to the guest > network). And then what? You need to find out where exactly (which pages) got the packets. If at all. I don't think you can do that from another VM, you probably are more lucky if you're the hypervisor. But I'm no security guy so I'm genuinely asking... In any case, it sounds hard to do. > And that's great! However, it is very different from "virtual machines > need not fully trust the hypervisor and administrator of their host > system" as said in the whitepaper. You know, those documents can be corrected ... :) > SEV protects pretty well from sibling VMs, but by design > this generation of SEV leaks a lot of information to an evil > host---probably more than enough to mount a ROP attack or to do evil > stuff that Andy outlined. > > My problem is that people will read AMD's whitepaper, not your message > on LKML, and may put more trust in SEV than (for now) they should. So if people rely on only one security feature, then they get what they deserve. And even non-security people like me know that proper security is layering of multiple features/mechanisms which should take care of aspects only, not of everything. And not a single magic wand which makes sh*t secure. :) So let's please get real: the feature is pretty elegant IMO and gives you a lot more security than before. Can it be made better/cover more aspects? Absolutely and it is a safe bet that it will be. You don't just implement stuff like that in hw to not improve on it in future iterations. It is like with all hardware features, they get improved with time and CPU revisions. Now, can people please look at the actual code and complain about stuff that bothers them codewise? We've tried to make it as unobtrusive as possible to the rest of the kernel but improvement suggestions are always welcome! :-) Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.