linux-kernel - [PATCH] add support for larger files in minix filesystem

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-next>] [day] [month] [year] [list]

Message-ID: <CA+jjjYSYafLBu+u6MNZG+0Tj=zgVmVVz-mTqwDgPq_-G3xChOQ@mail.gmail.com>
Date:	Sun, 1 Nov 2015 19:56:36 -0800
From:	Joshua Hudson <joshudson@...il.com>
To:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: [PATCH] add support for larger files in minix filesystem

From: Joshua Hudson <joshudson@...il.com>

The Minix v3 filesystem and kernel driver have no actual dependency on files
being less than 2GB in size; however the kernel does not allow creating a
file of 2GB or larger on a Minix v3 filesystem. I was able to remove the pseudo-
dependency easily by changing one line of code (filesystems need to tell VFS
how big of files they allow).

This code won't do anything useful unless the filesystem superblock is
patched at offset 1040 to a larger value. The largest safe value is
0,252,255,255.

Signed-off-by Joshua Hudson <joshudson@...il.com>
---
I'm not on the list anymore so if you don't CC me I won't see it.

Background: I've been playing around with work on a new embedded device.
where the hardware simply isn't powerful enough to sustain ext2 filesystem.
This resulted in me choosing the Minix filesystem as the operational filesystem
for reasons including find-next-free-block is sixteen times faster than FAT.
I discovered the need to collect about 3gb of sensor data in one tape-like run.
Naturally, this leads to creating a 3gb file; but Linux Kernel can't
handle that.

Please note I'm pretty far down branches and I don't think a stock kernel
will run on my system (non-free hardware drivers). Thankfully the Minix fs
code changes so slowly this should apply all the same. I have tested that
the patch applies and builds a kernel that fixes the problem.

The fact that the superblock has to be edited for the patch to do anything
interesting (else it replaces s_maxbytes with the same value) makes this
quite safe to apply even in the presence of a bug I don't know about.

--- linux-4.2.3/fs/minix/inode.c.orig   2015-11-01 17:13:57.227148723 -0800
+++ linux-4.2.3/fs/minix/inode.c        2015-11-01 17:21:49.785390753 -0800
@@ -232,6 +232,7 @@
                s->s_max_links = MINIX2_LINK_MAX;
        } else
                goto out_no_fs;
+       s->s_maxbytes = (unsigned)sbi->s_max_size; /* s_max_size
cannot be >=4GB and MAX_LFS_SIZE must be >= 4GB */

        /*
         * Allocate the buffer map to keep the superblock small.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/