From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AB8JxZogqcvzqZnxAbeYA74zVFWmkqFpaKoOUiziIuQL3u8iqwWd3p99Hx6QaiVTjvgApMjSWjhM ARC-Seal: i=1; a=rsa-sha256; t=1525205200; cv=none; d=google.com; s=arc-20160816; b=HgYbSBDfBdMT6Tm6/ExPlG7bgH+t1Ru7mJoAss5X7ThjH4kf6yApkySSTkNNq4hiKj DtVbYCG8GpSE51VTpaSDmeY4kZZBXt4SSGjWU1Nk0FBsSxYw09xh1+j3e7roVKCxje1j mySq2sLsJcAfCNJWXnDF/XGW4+5ZnILSw8Wn+q6wUeGD72OrZGToQyeKPJZTkD8csVB7 Wo8ckzM7eiWbBlYi5J/BaORKgPtmgPL5gL1OW486qomN9JHKUDTCIORI8TonMzy0qeuU 9cKOXnornpnAv8Fx+owjWPBIJZ52fNlWrTULr1LZ4pkwzgMv5mP1aaiupxhu6CcG32kw YWlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:arc-authentication-results; bh=TYzt7dlomvLmqbmXxZqRigp16+Yt3zBmVSeT2kWBSGU=; b=uB3CNmY06q2bnEwM83QUo58h3i18pae+CuaUD9jd9QXghyh0zPAZe1cz5WNwVTnRvW +MliJtgOFRlQsjaaqjvkR9R7ydw+eiEJT5Nbr6ctHJDrOO49teyAIzTfvaMsygiEgUCy gGj5ILs1pvlYSIhRWXy0+NW0OITfKsojj2wYdKVAK9SGH/UY7FaQN3nofjHqVuz5d1pi qjA31/T9TI0LVRD5W4dCMXNthyNqY87VNt+uwQ9bZKs9dVaqpsmHTXoIAmAJaqUDcR/m rG8ZNWpQwWumRA3cFoNMxiAKQdq2CwxE02gwJbU4HxNg8HqtNB7P5PpwD2hRc1u27j7n rJAA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of foo00@h08.hostsharing.net designates 176.9.242.62 as permitted sender) smtp.mailfrom=foo00@h08.hostsharing.net Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of foo00@h08.hostsharing.net designates 176.9.242.62 as permitted sender) smtp.mailfrom=foo00@h08.hostsharing.net Date: Tue, 1 May 2018 22:06:39 +0200 From: Lukas Wunner To: Andy Lutomirski Cc: Hans de Goede , Ard Biesheuvel , "Luis R. Rodriguez" , Greg KH , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Peter Jones , dave@bewaar.me, Will Deacon , Matt Fleming , David Howells , Mimi Zohar , Josh Triplett , Dmitry Torokhov , Martin Fuzzey , Kalle Valo , Arend Van Spriel , Linus Torvalds , nbroeking@me.com, Bjorn Andersson , duwe@suse.de, Kees Cook , X86 ML , linux-efi , LKML , LSM List Subject: Re: [PATCH v5 2/5] efi: Add embedded peripheral firmware support Message-ID: <20180501200639.GA3628@wunner.de> References: <20180429093558.5411-1-hdegoede@redhat.com> <20180429093558.5411-3-hdegoede@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1599072709046551146?= X-GMAIL-MSGID: =?utf-8?q?1599293568305924327?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Tue, May 01, 2018 at 07:29:19PM +0000, Andy Lutomirski wrote: > On Sun, Apr 29, 2018 at 2:36 AM Hans de Goede wrote: > > + for (i = 0; i < size; i += 8) { > > + if (*((u64 *)(mem + i)) != *((u64 *)desc->prefix)) > > + continue; > > + > > + /* Seed with ~0, invert to match crc32 userspace utility > */ > > + crc = ~crc32(~0, mem + i, desc->length); > > + if (crc == desc->crc) > > + break; > > + } > > I hate to play the security card, but this stinks a bit. The kernel > obviously needs to trust the EFI boot services code since the EFI boot > services code is free to modify the kernel image. But your patch is not > actually getting this firmware blob from the boot services code via any > defined interface -- you're literally snarfing up the blob from a range of > memory. I fully expect there to be any number of ways for untrustworthy > entities to inject malicious blobs into this memory range on quite a few > implementations. [snip] > It would be really nice if there was a way to pull a blob out of EFI space > that is marked, by EFI, as belonging to a particular device. Upthread I suggested to read the firmware from the EFI Firmware Volume. >>From my point of view that would fulfill your requirements: https://lkml.org/lkml/2018/4/3/568 In the case of Hans' HID device, the firmware is embedded as a binary array in the EFI driver for the device. So the kernel would read the driver from the Firmware Volume, but it would still have to extract the firmware from the driver, either by scanning for the 8 byte magic or by hardcoding the offset and length in the kernel. An attacker would have to modify the Firmware Volume as opposed to just modifying a particular space in memory. My suggestion was dismissed by Hans and Peter Jones on the grounds of causing additional work without perceived benefit, given that a working (albeit admitted to be hackish) solution exists. Moreover Ard criticized that the EFI Firmware Volume Protocol is not part of the UEFI spec. I agree with you completely BTW. Thanks, Lukas