linux-kernel - Re: [PATCH] fat: Relax checks for sector size and media type

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <878t47roio.fsf@mail.parknet.co.jp>
Date:   Wed, 12 Sep 2018 19:36:15 +0900
From:   OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:     Pali Rohár <pali.rohar@...il.com>
Cc:     linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] fat: Relax checks for sector size and media type

Pali Rohár <pali.rohar@...il.com> writes:

>> If there is real user to use that, I'm ok though (of course, need
>> serious tests). However, FAT would be for exchange data with other
>> devices, and there is "cluster per sector", and spec recommends sector
>> size == device sector size. So I suspect this format is not useful.
>
> I looked into OpenBSD, FreeBSD and NetBSD source code and there is no
> explicit upper limit for sector size. Just that sector size must be
> power of two.
>
> I have not did tests yet, but you are right that some testing should be
> done.
>
> As FAT operates with clusters and cluster size is defined by sector
> size, then sectors per cluster and sector size defines cluster size. And
> cluster size itself implies maximal size of FAT filesystem.
>
> So increasing sector size could be useful to create larger FAT32
> filesystems as current limit hit by sector size = 512 bytes.
>
> What do you think, which operating systems should be tested?

Again, I suspect those custom extension (can't read by some uefi or
windows) is not useful though.

Testing on kernel that has PAGE_SIZE >= 8192, and setting FAT
sector_size >= 8192.  After that, it would be safe to remove 4096
limitation.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>