From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=intel.com (client-ip=192.55.52.88; helo=mga01.intel.com; envelope-from=ed.tanous@intel.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=intel.com Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 41ksBc49tHzDq6t for ; Tue, 7 Aug 2018 08:04:37 +1000 (AEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Aug 2018 15:04:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,452,1526367600"; d="scan'208";a="61097632" Received: from hades.jf.intel.com (HELO [10.54.51.77]) ([10.54.51.77]) by fmsmga008.fm.intel.com with ESMTP; 06 Aug 2018 14:57:59 -0700 Subject: Re: In-Band Firmware Update To: openbmc@lists.ozlabs.org References: <20180723221837.GI105329@mauery> <7BB65E38-8F1D-4723-B1C5-74102D4D0B20@fb.com> <6491f54b7b2da630cd3796c6bc3a5214@linux.vnet.ibm.com> From: Ed Tanous Message-ID: <712b9342-6458-4cc4-8c59-aeb498ca5367@intel.com> Date: Mon, 6 Aug 2018 14:59:28 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <6491f54b7b2da630cd3796c6bc3a5214@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: openbmc@lists.ozlabs.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Development list for OpenBMC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 22:04:42 -0000 > > We are going to investigate using the DFU protocol, as that > also has host side tools already available. > DFU doesn't completely solve the issue though, does it? Presumably for security reasons you can't have the DFU device exposed to the host all the time. If you did, I'm sure the penetration testers would hit it hard. Assuming that leaving it available all the time is a non-starter, don't you need some command to activate the interface to allow the upload? Assuming I'm not missing something there (I probably am) doesn't it make more sense to just expose a USB mass storage device when the "start" command is sent, as opposed to implementing the full DFU protocol? It seems like that would require no utilities (aside from a simple nsh/bash script) and be very easy to replicate. Is there any more details on this approach?