[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160426215952.44ff82a6@lxorguk.ukuu.org.uk>
Date: Tue, 26 Apr 2016 21:59:52 +0100
From: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To: Pavel Machek <pavel@....cz>
Cc: Andy Lutomirski <luto@...capital.net>,
Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
Greg KH <gregkh@...uxfoundation.org>,
Andy Lutomirski <luto@...nel.org>,
Borislav Petkov <bp@...e.de>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
"open list:STAGING SUBSYSTEM" <devel@...verdev.osuosl.org>,
Ingo Molnar <mingo@...nel.org>,
Kristen Carlson Accardi <kristen@...ux.intel.com>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>,
Mathias Krause <minipli@...glemail.com>,
Thomas Gleixner <tglx@...utronix.de>,
Wan Zongshun <Vincent.Wan@....com>
Subject: Re: [PATCH 0/6] Intel Secure Guard Extensions
> 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
Powered by blists - more mailing lists