From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751385AbeAYU0w (ORCPT ); Thu, 25 Jan 2018 15:26:52 -0500 Received: from alln-iport-4.cisco.com ([173.37.142.91]:53996 "EHLO alln-iport-4.cisco.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751227AbeAYU0u (ORCPT ); Thu, 25 Jan 2018 15:26:50 -0500 X-IronPort-AV: E=Sophos;i="5.46,413,1511827200"; d="scan'208";a="61713563" Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 To: Arnd Bergmann From: Taras Kondratiuk In-Reply-To: Cc: "H. Peter Anvin" , Al Viro , Rob Landley , Mimi Zohar , Jonathan Corbet , James McMechan , initramfs@vger.kernel.org, Victor Kamensky , linux-doc@vger.kernel.org, Linux Kernel Mailing List , LSM List , xe-linux-external@cisco.com References: <1516850875-25066-1-git-send-email-takondra@cisco.com> <1516850875-25066-2-git-send-email-takondra@cisco.com> Message-ID: <151691200536.5378.11544479301138437367@takondra-t460s> User-Agent: alot/0.6 Subject: Re: [PATCH v2 01/15] Documentation: add newcx initramfs format description Date: Thu, 25 Jan 2018 12:26:45 -0800 X-Auto-Response-Suppress: DR, OOF, AutoReply Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id w0PKQw5d007413 Quoting Arnd Bergmann (2018-01-25 01:29:12) > On Thu, Jan 25, 2018 at 4:27 AM, Taras Kondratiuk wrote: > > Many of the Linux security/integrity features are dependent on file > > metadata, stored as extended attributes (xattrs), for making decisions. > > These features need to be initialized during initcall and enabled as > > early as possible for complete security coverage. > > > > Initramfs (tmpfs) supports xattrs, but newc CPIO archive format does not > > support including them into the archive. > > > > This patch describes "extended" newc format (newcx) that is based on > > newc and has following changes: > > - extended attributes support > > - increased size of filesize to support files >4GB. > > - increased mtime field size to have usec precision and more than > > 32-bit of seconds. > > - removed unused checksum field. > > > > Signed-off-by: Taras Kondratiuk > > Signed-off-by: Mimi Zohar > > Signed-off-by: Victor Kamensky > > Ah nice, I like the extension of the time handling, that certainly > addresses one of the issues with y2038 that we have previously > hacked around in an ugly way (interpreting the 32-bit > number as unsigned). > > However, if this is to become a generally supported format > for cpio files, could we make it use nanosecond resolution > instead? The issue that I see with microseconds is that > storing a file in an archive and extracting it again would > otherwise keep the mtime stamp /almost/ identical on file > systems that have nanosecond resolution, but most of > the time a comparison would indicate that the files are > not the same. > > Unfortunately, the range of a 64-bit nanoseconds counter > is still a bit limited (584 years, or half of that if we make it > signed). While this is clearly enough for the uses in > initramfs, it still has a similar problem: someone creating > a fake timestamp a long time in the past or future on > a file system would lose information after going though > cpio. We can match statx(2) by having 64 bits for seconds plus 32 bits for nanoseconds. For initramfs nanoseconds field can be ignored during unpacking.