linux-kernel - Re: [RFC] udf: 2.01 interoperability issues with Windows 10

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

Date:   Tue, 9 Jul 2019 21:55:35 +0200
From:   Jan Kara <jack@...e.cz>
To:     Steve Magnani <steve.magnani@...idescorp.com>
Cc:     Jan Kara <jack@...e.cz>,
        Pali Rohár <pali.rohar@...il.com>,
        linux-fsdevel@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] udf: 2.01 interoperability issues with Windows 10

Hi!

On Tue 09-07-19 13:27:58, Steve Magnani wrote:
> Recently I have been exploring Advanced Format (4K sector size)
> and high capacity aspects of UDF 2.01 support in Linux and
> Windows 10. I thought it might be helpful to summarize my findings.
> 
> The good news is that I did not see any bugs in the Linux
> ecosystem (kernel driver + mkudffs).
> 
> The not-so-good news is that Windows has some issues that affect
> interoperability. One of my goals in posting this is to open a
> discussion on whether changes should be made in the Linux UDF
> ecosystem to accommodate these quirks.
> 
> My test setup includes the following software components:
> 
> * mkudffs 1.3 and 2.0
> * kernel 4.15.0-43 and 4.15.0-52
> * Windows 10 1803 17134.829
> * chkdsk 10.0.17134.1
> * udfs.sys 10.0.17134.648
> 
> 
> ISSUE 1: Inability of the Linux UDF driver to mount 4K-sector
>          media formatted by Windows.
> 
> This is because the Windows ecosystem mishandles the ECMA-167
> corner case that requires Volume Recognition Sequence components
> to be placed at 4K intervals on 4K-sector media, instead of the
> 2K intervals required with smaller sectors. The Linux UDF driver
> emits the following when presented with Windows-formatted media:
> 
>   UDF-fs: warning (device sdc1): udf_load_vrs: No VRS found
>   UDF-fs: Scanning with blocksize 4096 failed
> 
> A hex dump of the VRS written by the Windows 10 'format' utility
> yields this:
> 
>   0000: 00 42 45 41 30 31 01 00 00 00 00 00 00 00 00 00  .BEA01..........
>   0800: 00 4e 53 52 30 33 01 00 00 00 00 00 00 00 00 00  .NSR03..........
>   1000: 00 54 45 41 30 31 01 00 00 00 00 00 00 00 00 00  .TEA01..........
> 
> We may want to consider tweaking the kernel UDF driver to
> tolerate this quirk; if so a question is whether that should be
> done automatically, only in response to a mount option or
> module parameter, or only with some subsequent confirmation
> that the medium was formatted by Windows.

Yeah, I think we could do that although it will be a bit painful. I would
do it by default if we found BEA descriptor but not NSR descriptor. We do
already have handling for various quirks of other udf creators so this is
nothing new... I think Palo replied about the rest of the issues you've
found.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR