From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751543AbeAYJ3T (ORCPT ); Thu, 25 Jan 2018 04:29:19 -0500 Received: from mail-oi0-f65.google.com ([209.85.218.65]:46135 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751378AbeAYJ3O (ORCPT ); Thu, 25 Jan 2018 04:29:14 -0500 X-Google-Smtp-Source: AH8x225aFZ1JskQVBZ6rhmPcyNm7BOFc/wmyZWDzm0/DDWg8jaoDvs2s47f/JB0pdbo5NSgjyroPsyAMIvWofzsGgQ0= MIME-Version: 1.0 In-Reply-To: <1516850875-25066-2-git-send-email-takondra@cisco.com> References: <1516850875-25066-1-git-send-email-takondra@cisco.com> <1516850875-25066-2-git-send-email-takondra@cisco.com> From: Arnd Bergmann Date: Thu, 25 Jan 2018 10:29:12 +0100 X-Google-Sender-Auth: 1fk485KKSzj6tZkyFmolNadDjB0 Message-ID: Subject: Re: [PATCH v2 01/15] Documentation: add newcx initramfs format description To: Taras Kondratiuk 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Arnd