linux-kernel - Re: [PATCH v10 7/8] powerpc: Move arch_ima_add_kexec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49408f07b91685e058f94844e73c753bb2033d35.camel@linux.ibm.com>
Date:   Mon, 07 Dec 2020 09:57:54 -0500
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>,
        Thiago Jung Bauermann <bauerman@...ux.ibm.com>
Cc:     robh@...nel.org, gregkh@...uxfoundation.org, james.morse@....com,
        catalin.marinas@....com, sashal@...nel.org, will@...nel.org,
        mpe@...erman.id.au, benh@...nel.crashing.org, paulus@...ba.org,
        robh+dt@...nel.org, frowand.list@...il.com,
        vincenzo.frascino@....com, mark.rutland@....com,
        dmitry.kasatkin@...il.com, jmorris@...ei.org, serge@...lyn.com,
        pasha.tatashin@...een.com, allison@...utok.net,
        kstewart@...uxfoundation.org, takahiro.akashi@...aro.org,
        tglx@...utronix.de, masahiroy@...nel.org, bhsharma@...hat.com,
        mbrugger@...e.com, hsinyi@...omium.org, tao.li@...o.com,
        christophe.leroy@....fr, linux-integrity@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        prsriva@...ux.microsoft.com, balajib@...ux.microsoft.com
Subject: Re: [PATCH v10 7/8] powerpc: Move arch_ima_add_kexec_buffer to ima

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@...ux.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