From owner-freebsd-questions@freebsd.org Fri Aug 10 15:24:27 2018 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26CD9106DF00 for ; Fri, 10 Aug 2018 15:24:27 +0000 (UTC) (envelope-from galtsev@kicp.uchicago.edu) Received: from kicp.uchicago.edu (kicp.uchicago.edu [128.135.20.70]) by mx1.freebsd.org (Postfix) with ESMTP id C14878F8E2 for ; Fri, 10 Aug 2018 15:24:26 +0000 (UTC) (envelope-from galtsev@kicp.uchicago.edu) Received: from point.uchicago.edu (point.uchicago.edu [128.135.52.6]) by kicp.uchicago.edu (Postfix) with ESMTP id 607BC7180EF for ; Fri, 10 Aug 2018 10:24:20 -0500 (CDT) Subject: Re: Erase memory on shutdown To: freebsd-questions@freebsd.org References: <20180805150241.1E186200349F8E@ary.qy> <4e70e969-14f7-c65d-96d2-dd1610499cd0@irk.ru> <63033.108.68.162.197.1533484522.squirrel@cosmo.uchicago.edu> From: Valeri Galtsev Message-ID: <915020aa-65ba-7b8c-8676-40e41dc77c0a@kicp.uchicago.edu> Date: Fri, 10 Aug 2018 10:24:19 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 15:24:27 -0000 On 08/10/18 09:08, cpghost wrote: > On 08/05/18 17:55, Valeri Galtsev wrote: >> Another route could be encryption of RAM on-the-fly while system runs, yet >> it is questionable where the encryption key itself is kept to be >> unaccessible for the attacker in the attack above, and boot of such system >> may require warm body present. > > What about SEV? > > https://developer.amd.com/amd-secure-memory-encryption-sme-amd-secure-encrypted-virtualization-sev/ > https://github.com/AMDESE/AMDSEV I personally am an opponent of the other processor in my machine that has almighty access to my machine, can access external hosts via the same physical network connection though not controllable by me, the sysadmin of the machine (or machine owner). It sounds to me that it is in the same general direction as Intel ME. Out of two bads I choose the lesser bad. Namely: the possibility of attack by the bad guy who has physical access to my machine is lesser bad than the possibility of attack through super-system which I have no way to modify, control, or turn off, that runs on another CPU, has control over my hardware that runs my system, and my system is a slave to that super-system. Do you think it is your machine? No, it is their machine (whoever they are). There is one (small?) company that tries to rid of all proprietary code and other means of control, thus giving the owner full possession of his hardware ("impregnable" for third parties, be it even the main CPU manufacturer): https://puri.sm/ https://puri.sm/posts/purism-librem-laptops-completely-disable-intel-management-engine/ They also implement open source coreboot instead of proprietary EFI or BIOS. And they do not have in their hardware anything that requires available as binary only "firmware" or "microcode". So, they use famous Atheros WiFi, but they never use working great but running proprietary firmware Intel WiFi. I'd like to hear if anyone knows about similar efforts by other computer manufacturers. Sorry, this went a bit off the original point (but not quite off of it). Valeri > >> Valeri > > -cpghost. > -- ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++