Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1603915pxu; Thu, 17 Dec 2020 14:06:18 -0800 (PST) X-Google-Smtp-Source: ABdhPJy5G+pQqt8krRbvAH4sNqWz4lAN3DqAi8hmcw6/s5trDI9yxT9v0YvJR8MRupfwAeSGBrYT X-Received: by 2002:a17:906:4d8d:: with SMTP id s13mr1093101eju.305.1608242778808; Thu, 17 Dec 2020 14:06:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608242778; cv=none; d=google.com; s=arc-20160816; b=X059/kyToZZ3CjnDbg142SuVoTn0Lgqhf5nxcx28SWg29vu8i9oyhpDp3ImGHjFytF RQcbSIZbhhwFCgW5OwJ2EY/roSLc0iLUerXfJFBfviTI5BpkcNRnPRQ2jrG8ayLGbMhH 7OytqWnXiQU3sY6ZD1gfhePGU05vIs06kwGeQ+yYDf9X1WWt18MDXepWZPcr1uue48Oj vQekm+9hXIVFhXtAtOfFArgwAIjSUs3JZo146hYbzdJnmSyb3zVHDGZ1OMmB8xEmE4EO 0P049lxeVtW+V3Lu8sNXVC40JSva2mSfsJm14hFYku6Recw3VO/aYlMvcF9TYGmSM9tX tbTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Ep7s93Yoq8grmue+A1ZJQdAqhk5m/WUxDjR/7t4WeOA=; b=QBY7yGXS+D+v/plRE+Csa+u1pZPnU0aswlSixSrE9LaTg2fOBMmmVD9jMGjNmOxL9N mJT/bWPt6pX5hQ9mN+CV7bRgL0uTLHRJAOhoI6pjfWDWbSF5x4CL6MHaxTIoCK1yPAlN l9mP8DTzMKUbFH/ExqikpFw20/4v3gaVk9yL8I7jxxxhxL0Sz8C5zWHW1eQ9lQjSixtp ZlLq5IvpejeH7MA0Fa+art5TCAcv9mKKiZ3hW4bants2Q5voPYnm0A/V+DSL88+KeG2a SueGUPaXIO4alSd6+2rfEusnxRTMZ8V9fhoFW6I8+PU8gaLdeJc7lBM67LrQK90IAVgF aIGA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=qXFm60Gq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m16si3486922ejj.44.2020.12.17.14.05.56; Thu, 17 Dec 2020 14:06:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=qXFm60Gq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731953AbgLQWCY (ORCPT + 99 others); Thu, 17 Dec 2020 17:02:24 -0500 Received: from mail.kernel.org ([198.145.29.99]:38476 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727132AbgLQWCX (ORCPT ); Thu, 17 Dec 2020 17:02:23 -0500 X-Gm-Message-State: AOAM530ZkZhiarVGzJ6OZojQMghmwUQB4SBiFJlBpTM+RSDPZT8GWP08 QW/jnC4uUPSQUZdOW2dtHi9Mc8Vr6AK/TiQsKg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1608242502; bh=Tvn9jrecEQspYro+q9S2fWwt824cwVXTxc9Kum0JJ/w=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=qXFm60GqKVBH/gTpEe/wzO4dP4IVQ5Uqg70JiTCF8T5e3iAoPJIUA+qaP2IwbKWTW 50u2qUkasgq8ibYgrKzahMbQ8juu+gAK9jKY/upWV9tlszh4k+b5BCX95R2uG71jB4 XWY/yJD37tIaSk8hLpaQt7Ixc0xnSftp1KRELT2loYIBlBM/GRAlX1jdB/QUbc4VKi O4VAjom/G1gTazl7XbTSeZi9PX5T5zsnmS89Pk6e6FLWe8G9WWeIyP7a1mj3wiejEy 3aciomts1pBHNfjyK5fvGGtfCEIlnWai2+H1xRIz2f6aihHH1DrtdHHo4Q1RbOG2Q+ YAYZrur7+qmIA== X-Received: by 2002:a17:906:d784:: with SMTP id pj4mr1079986ejb.360.1608242500803; Thu, 17 Dec 2020 14:01:40 -0800 (PST) MIME-Version: 1.0 References: <20201217173708.6940-1-nramas@linux.microsoft.com> <20201217173708.6940-3-nramas@linux.microsoft.com> <20201217200510.GA105447@robh.at.kernel.org> <0b17fbee-cfe9-8cb2-01d1-02b6a61a14f5@linux.microsoft.com> In-Reply-To: <0b17fbee-cfe9-8cb2-01d1-02b6a61a14f5@linux.microsoft.com> From: Rob Herring Date: Thu, 17 Dec 2020 16:01:28 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v12 2/4] powerpc: Move arch independent ima kexec functions to drivers/of/kexec.c To: Lakshmi Ramasubramanian Cc: Mimi Zohar , Thiago Jung Bauermann , "AKASHI, Takahiro" , Greg Kroah-Hartman , Will Deacon , Catalin Marinas , Michael Ellerman , James Morse , Sasha Levin , Benjamin Herrenschmidt , Paul Mackerras , Frank Rowand , vincenzo.frascino@arm.com, Mark Rutland , dmitry.kasatkin@gmail.com, James Morris , "Serge E. Hallyn" , Pavel Tatashin , Allison Randal , Masahiro Yamada , Bhupesh Sharma , Matthias Brugger , Hsin-Yi Wang , tao.li@vivo.com, Christophe Leroy , Prakhar Srivastava , balajib@linux.microsoft.com, linux-integrity@vger.kernel.org, "linux-kernel@vger.kernel.org" , linux-arm-kernel , devicetree@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 17, 2020 at 2:52 PM Lakshmi Ramasubramanian wrote: > > On 12/17/20 12:05 PM, Rob Herring wrote: > > On Thu, Dec 17, 2020 at 09:37:06AM -0800, Lakshmi Ramasubramanian wrote: > >> The functions defined in "arch/powerpc/kexec/ima.c" handle setting up > >> and freeing the resources required to carry over the IMA measurement > >> list from the current kernel to the next kernel across kexec system call. > >> These functions do not have architecture specific code, but are > >> currently limited to powerpc. [...] > >> +#ifdef CONFIG_IMA_KEXEC > >> +/** > >> + * arch_ima_add_kexec_buffer - do arch-specific steps to add the IMA buffer > >> + * > >> + * @image: kimage struct to set IMA buffer data > >> + * @load_addr: Starting address where IMA buffer is loaded at > >> + * @size: Number of bytes in the IMA buffer > >> + * > >> + * Architectures should use this function to pass on the IMA buffer > >> + * information to the next kernel. > >> + * > >> + * Return: 0 on success, negative errno on error. > >> + */ > >> +int arch_ima_add_kexec_buffer(struct kimage *image, unsigned long load_addr, > >> + size_t size) > > > > This should be a static inline in asm/kexec.h. > > arch_ima_add_kexec_buffer() is identical for powerpc and arm64. > Would it be better to "static inline" this function in "of.h" instead of > duplicating it in "asm/kexec.h" for powerpc and arm64? No, think about what it is specific to and place it there. It has nothing to do with DT really. All it is is a wrapper to access the struct members in kimage_arch. So it belongs where they are declared. Now perhaps ima_buffer_addr and ima_buffer_size shouldn't be arch specific, but that's a separate issue. Rob