From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933287AbcHJVOF (ORCPT ); Wed, 10 Aug 2016 17:14:05 -0400 Received: from smtp-out4.electric.net ([192.162.216.185]:60450 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932610AbcHJSH2 convert rfc822-to-8bit (ORCPT ); Wed, 10 Aug 2016 14:07:28 -0400 From: David Laight To: "'Petko Manolov'" , Mimi Zohar CC: "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 Thread-Topic: [Linux-ima-devel] [PATCH 1/7] ima: on soft reboot, restore the measurement list Thread-Index: AQHR8xQC8z1VxfHCT0yKu72cPwcU3aBCQ2pw Date: Wed, 10 Aug 2016 14:40:13 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6D5F50F2BB@AcuExch.aculab.com> 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> In-Reply-To: <20160810143230.GD4087@localhost> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuExch.aculab.com X-TLS: TLSv1:AES128-SHA:128 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. The extra bytes will make 0 difference to the allocation cost and lots to the processing. David