Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753184AbcDZVAc (ORCPT ); Tue, 26 Apr 2016 17:00:32 -0400 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:43540 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752297AbcDZVAa (ORCPT ); Tue, 26 Apr 2016 17:00:30 -0400 Date: Tue, 26 Apr 2016 21:59:52 +0100 From: One Thousand Gnomes To: Pavel Machek Cc: Andy Lutomirski , Jarkko Sakkinen , Greg KH , Andy Lutomirski , Borislav Petkov , Boris Ostrovsky , "open list:STAGING SUBSYSTEM" , Ingo Molnar , Kristen Carlson Accardi , "open list:DOCUMENTATION" , open list , Mathias Krause , Thomas Gleixner , Wan Zongshun Subject: Re: [PATCH 0/6] Intel Secure Guard Extensions Message-ID: <20160426215952.44ff82a6@lxorguk.ukuu.org.uk> In-Reply-To: <20160426201154.GC11111@amd> References: <1461605698-12385-1-git-send-email-jarkko.sakkinen@linux.intel.com> <20160426190009.GC8162@amd> <20160426194117.GA11111@amd> <20160426201154.GC11111@amd> Organization: Intel Corporation X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1011 Lines: 28 > But... that will mean that my ssh will need to be SGX-aware, and that > I will not be able to switch to AMD machine in future. ... or to other > Intel machine for that matter, right? I'm not privy to AMD's CPU design plans. However I think for the ssl/ssh case you'd use the same interfaces currently available for plugging in TPMs and dongles. It's a solved problem in the crypto libraries. > What new syscalls would be needed for ssh to get all this support? I don't see why you'd need new syscalls. > Ookay... I guess I can get a fake Replay Protected Memory block, which > will confirm that write happened and not do anything from China, but It's not quite that simple because there are keys and a counter involved but I am sure doable. > And, again, it means that quite complex new kernel-user interface will > be needed, right? Why ? For user space we have perfectly good existing system calls, for kernel space we have existing interfaces to the crypto and key layers for modules to use. Alan