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;
Message-ID: <49408f07b91685e058f94844e73c753bb2033d35.camel@linux.ibm.com>
Subject: Re: [PATCH v10 7/8] powerpc: Move arch_ima_add_kexec_buffer to ima
From:   Mimi Zohar <zohar@linux.ibm.com>
To:     Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
        Thiago Jung Bauermann <bauerman@linux.ibm.com>
Cc:     robh@kernel.org, gregkh@linuxfoundation.org, james.morse@arm.com,
        catalin.marinas@arm.com, sashal@kernel.org, will@kernel.org,
        mpe@ellerman.id.au, benh@kernel.crashing.org, paulus@samba.org,
        robh+dt@kernel.org, frowand.list@gmail.com,
        vincenzo.frascino@arm.com, mark.rutland@arm.com,
        dmitry.kasatkin@gmail.com, jmorris@namei.org, serge@hallyn.com,
        pasha.tatashin@soleen.com, allison@lohutok.net,
        kstewart@linuxfoundation.org, takahiro.akashi@linaro.org,
        tglx@linutronix.de, masahiroy@kernel.org, bhsharma@redhat.com,
        mbrugger@suse.com, hsinyi@chromium.org, tao.li@vivo.com,
        christophe.leroy@c-s.fr, linux-integrity@vger.kernel.org,
        linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
        prsriva@linux.microsoft.com, balajib@linux.microsoft.com
Date:   Mon, 07 Dec 2020 09:57:54 -0500
In-Reply-To: <0f60b35e-eff6-20c6-363d-82f0b10a1c1f@linux.microsoft.com>
References: <20201204195149.611-1-nramas@linux.microsoft.com>
         <20201204195149.611-8-nramas@linux.microsoft.com>
         <87k0twlytt.fsf@manicouagan.localdomain>
         <0f60b35e-eff6-20c6-363d-82f0b10a1c1f@linux.microsoft.com>
Content-Type: text/plain; charset="ISO-8859-15"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Sun, 2020-12-06 at 18:03 -0800, Lakshmi Ramasubramanian wrote:
> On 12/5/20 1:36 PM, Thiago Jung Bauermann wrote:
> > 
> > Lakshmi Ramasubramanian <nramas@linux.microsoft.com> writes:
> 
> >> diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
> >> index 4d354593aecf..5263dafe8f4d 100644
> >> --- a/security/integrity/ima/ima_kexec.c
> >> +++ b/security/integrity/ima/ima_kexec.c
> >> @@ -74,6 +74,28 @@ static int ima_dump_measurement_list(unsigned long *buffer_size, void **buffer,
> >>   	return ret;
> >>   }
> >>   
> >> +/**
> >> + * 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.
> >> + */
> >> +static int arch_ima_add_kexec_buffer(struct kimage *image,
> >> +				     unsigned long load_addr,
> >> +				     size_t size)
> >> +{
> >> +	image->arch.ima_buffer_addr = load_addr;
> >> +	image->arch.ima_buffer_size = size;
> >> +
> >> +	return 0;
> >> +}
> >> +
> > 
> > Both powerpc and arm64 use the definition above for
> > arch_ima_add_kexec_buffer(), so it makes sense to share them as you do
> > in this patch. This file isn't the best one to put arch-specific code
> > which happens to be identical among architectures, but I can't think of
> > somewhere else to put it.
> > 
> > For now this isn't an issue since powerpc and arm64 are the only arches
> > implementing tihs feature. If a third arch implemented it and also used
> > the same function definition as above, it wouldn't be an issue either so
> > perhaps this is good enough for the time being? :-)
> 
> If Mimi doesn't have any objection, I'll leave this function in this 
> file. The other option is to move this function also to 
> "drivers/of/kexec.c".
> 
> Please let me know.

Defining arch_ima_add_kexec_buffer() function, as static, here in
ima_kexec.c is weird.  For this reason, I specifically asked Thiago to
look at it.  Thanks, Thiago, for looking and reviewing the rest of the
patch set.  Duplicating the code or defining it in drivers/of, doesn't
make sense either.  As Thiago suggested, define it here until there is
a reason to move it.

thanks,

Mimi