From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936250AbcHJUOZ (ORCPT ); Wed, 10 Aug 2016 16:14:25 -0400 Received: from lan.nucleusys.com ([92.247.61.126]:37956 "EHLO zztop.nucleusys.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S934099AbcHJS1q (ORCPT ); Wed, 10 Aug 2016 14:27:46 -0400 Date: Wed, 10 Aug 2016 18:48:49 +0300 From: Petko Manolov To: David Laight Cc: Mimi Zohar , "kexec@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Thiago Jung Bauermann , "linux-security-module@vger.kernel.org" , "linux-ima-devel@lists.sourceforge.net" , "linuxppc-dev@lists.ozlabs.org" Subject: Re: [Linux-ima-devel] [PATCH 1/7] ima: on soft reboot, restore the measurement list Message-ID: <20160810154849.GE4087@localhost> Mail-Followup-To: David Laight , Mimi Zohar , "kexec@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Thiago Jung Bauermann , "linux-security-module@vger.kernel.org" , "linux-ima-devel@lists.sourceforge.net" , "linuxppc-dev@lists.ozlabs.org" References: <1470313475-20090-1-git-send-email-zohar@linux.vnet.ibm.com> <3544655.o5QPxko4Ba@hactar> <87r39xthnv.fsf@concordia.ellerman.id.au> <18857164.IzlezsQllh@hactar> <87vaz9rlx2.fsf@concordia.ellerman.id.au> <1470833676.2881.183.camel@linux.vnet.ibm.com> <20160810143230.GD4087@localhost> <063D6719AE5E284EB5DD2968C1650D6D5F50F2BB@AcuExch.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D5F50F2BB@AcuExch.aculab.com> User-Agent: Mutt/1.6.0 (2016-04-01) X-Spam-Score: -1.0 (-) X-Spam-Report: Spam detection software, running on the system "zztop.nucleusys.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 16-08-10 14:40:13, David Laight wrote: > From: Linuxppc-dev [mailto:linuxppc-dev-bounces+david.laight=aculab.com@lists.ozlabs.org] On Behalf Of > > > > So given what you have above, you'd use something like: > > > > > > > > struct ima_kexec_hdr { > > > > u16 version; > > > > u16 _reserved0; > > > > u32 _reserved1; > > > > u64 buffer_size; > > > > u64 count; > > > > }; > > > > > > > > cheers > > > > > > Thanks, I'll make this change. > > > > I would suggest: > > > > struct ima_kexec_hdr { > > u64 buffer_size; > > u64 count; > > u16 version; > > }; > > > > and let the compiler add the proper padding, depending on the architecture. On > > 32bit machine we'll have 4 bytes smaller allocations (compared to 64bit) while > > retaining the same functionality. > > AAAArrrrgggg..... > > That doesn't work for 32bit applications on 64bit hosts. [...] Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 TVD_RCVD_IP Message was received from an IP address Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16-08-10 14:40:13, David Laight wrote: > From: Linuxppc-dev [mailto:linuxppc-dev-bounces+david.laight=aculab.com@lists.ozlabs.org] On Behalf Of > > > > So given what you have above, you'd use something like: > > > > > > > > struct ima_kexec_hdr { > > > > u16 version; > > > > u16 _reserved0; > > > > u32 _reserved1; > > > > u64 buffer_size; > > > > u64 count; > > > > }; > > > > > > > > cheers > > > > > > Thanks, I'll make this change. > > > > I would suggest: > > > > struct ima_kexec_hdr { > > u64 buffer_size; > > u64 count; > > u16 version; > > }; > > > > and let the compiler add the proper padding, depending on the architecture. On > > 32bit machine we'll have 4 bytes smaller allocations (compared to 64bit) while > > retaining the same functionality. > > AAAArrrrgggg..... > > That doesn't work for 32bit applications on 64bit hosts. Which part won't work? > The extra bytes will make 0 difference to the allocation cost and lots to the > processing. An example? Petko