Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp4130762ybg; Fri, 25 Oct 2019 13:49:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqyX9OeuE3/JTDdzweIlD6Wdg9SVA+DLPkdaXxUFO8Erh3ADy9xW9hTwtMuI1oQxf9fgQF7W X-Received: by 2002:a50:eb81:: with SMTP id y1mr6209687edr.119.1572036555003; Fri, 25 Oct 2019 13:49:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572036554; cv=none; d=google.com; s=arc-20160816; b=G+Ex1hWU458IIyhZbleZDiBy4A5uXT642t71DigNdkvNP+/qZIuHHAmw5EbMg8iENw 79C1liTIgpzyGP9ISrn4fuEugTvXVqPe8RnHztdCYmN81685y7zXZd+lBZk7/xyQ/VvU 4/XpXAcMt0mxjKVzqKkVIcwgwN58oiIYJtCXQErq85LBnUofvQfHqGxtGat8qnG5Im0+ hQsvrs3GOSRQmMq5jVlQ+els+Njs0MLi7P7NbX7wZH7V8UgqVlSrRLk7p6OkxDIEzfUd tDZTm1sFrVrPNN9WIoVZez3UDydF88vFAwFIL5J+aXBFZB8njq5dvTR6NS/n+3MyF6on 0Mhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:subject:from; bh=gtg/ZBA9dW4LZxCsqjxhPr7EkbkAVQkmDQb2XNJYVnk=; b=dPxyWGIUmLsxncLoCTqalTxgAGB8hh2VeTNMfh9fH9iIZKA2ropx8eFCJbCLGAtiCr bMgEXqoaXR6MPOFNfZNeLICK2WgX6v8FX0K4zW+L3nLSXC9SMG+Lw7WQKx1qDX3Qvtes azpsnakdZMQvsUIEC5r9yI00m05IY2z4YxQP5me3aMcaJ53zsEW/gNnDWgm4fkeD0Umz t597BeqsyZUskoVB46lu1fE+KhPSnKxzDa1oUZWD9ma3ECzTDtgsJk4Ct2tj5QDl1cI4 I0OeT+Yyd+eqw0+cmr9tgVw1TrIhIUZmmu6JzAIYhg15hv2N27ym4DISWAK8OztMvGOd g+Uw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m22si1663039ejr.368.2019.10.25.13.48.51; Fri, 25 Oct 2019 13:49:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2505847AbfJYRI4 (ORCPT + 99 others); Fri, 25 Oct 2019 13:08:56 -0400 Received: from foss.arm.com ([217.140.110.172]:43400 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2505835AbfJYRIV (ORCPT ); Fri, 25 Oct 2019 13:08:21 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4299D328; Fri, 25 Oct 2019 10:08:20 -0700 (PDT) Received: from [10.1.196.105] (eglon.cambridge.arm.com [10.1.196.105]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C4B993F71A; Fri, 25 Oct 2019 10:08:17 -0700 (PDT) From: James Morse Subject: Re: [PATCH V4 0/2] Add support for arm64 to carry ima measurement To: Pavel Tatashin Cc: prsriva , LKML , Linux ARM , linux-integrity@vger.kernel.org, kexec mailing list , Mark Rutland , jean-philippe@linaro.org, arnd@arndb.de, takahiro.akashi@linaro.org, sboyd@kernel.org, Catalin Marinas , zohar@linux.ibm.com, Masahiro Yamada , duwe@lst.de, bauerman@linux.ibm.com, Thomas Gleixner , allison@lohutok.net, Ard Biesheuvel References: <20191011003600.22090-1-prsriva@linux.microsoft.com> <87d92514-e5e4-a79f-467f-f24a4ed279b6@arm.com> <0053eb68-0905-4679-c97a-00c5cb6f1abb@arm.com> Message-ID: Date: Fri, 25 Oct 2019 18:08:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Pavel, On 15/10/2019 19:47, Pavel Tatashin wrote: >> I think the UEFI persistent-memory-reservations thing is a better fit for this [0][1]. > Thank you for your thought. As I understand you propose the to use the > existing method as such: > 1. Use the existing kexec ABI to pass reservation from kernel to > kernel using EFI the same as is done for GICv3 tables. > 2. Allow this memory to be reservable only during first Linux boot via > EFI memory reserve > 3. Allow to have this memory pre-reserved by firmware or to be > embedded into device tree. > > A question I have is how to tell that a reserved region is reserved > for IMA use. With GICv3 it is done by reading the registers, finding > the interrupt tables memory, and check that the memory ranges are > indeed pre-reserved. Good point, efi_mem_reserve_persistent() has no way of describing what a region is for, you have to know that from somewhere else. > Is there a way to name memory with the current ABI that you think is acceptable? This would need to go in the chosen node of the DT, like power-pc already does. This would work on arm64:ACPI systems too (because they have a DT chosen node). I'd like to understand why removing these entries is needed, it doesn't look like we have an API call to remove them from the efi mem-reserve... If it had a fixed position in memory its the sort of thing we'd expect firmware to reserved during boot. (e.g. ramoops). ~ From ima_add_kexec_buffer() this really is a transient memory reservation over kexec. I think the efi mem-reserve and a DT-chosen node entry with the PA is the only way to make this work smoothly between DT<->ACPI systems. We'd need a way of removing the efi mem-reserve in ima_free_kexec_buffer(), otherwise the memory remains lost. The DT-chosen node entry should have its pointer zero'd out once we've done this. (like we do for the KASLR seed). Not considered is parsing the DT-chosen node entry as if it were a memreserve during early boot. This wouldn't work if you kexec something that doesn't know what the node is, it would overwrite the the memory and may not remove the node for the next kexec, which does. Thanks, James