linux-kernel - Re: Mounting BorderWare UFS File Systems

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]

Message-Id: <20100512135603.b0a6777b.akpm@linux-foundation.org>
Date:	Wed, 12 May 2010 13:56:03 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Thomas Stewart <thomas@...warts.org.uk>
Cc:	linux-kernel@...r.kernel.org, Evgeniy Dushistov <dushistov@...l.ru>
Subject: Re: Mounting BorderWare UFS File Systems

On Tue, 11 May 2010 22:53:04 +0100
Thomas Stewart <thomas@...warts.org.uk> wrote:

> Hi,
> 
> I recently had to recover some files from an old broken machine that was
> running BorderWare Document Gateway. It's basically a drop in web server
> for sharing files. From the look of the init process and using strings
> on of a few files it seems to be based on FreeBSD 3.3. The process
> turned out to be more difficult than I imagined, but to cut a long story
> short BorderWare in their wisdom use a nonstandard magic number in their
> UFS (ufstype=44bsd) file systems. Thus Linux refuses to mount the file
> systems in order to recover the data. After a bit of hunting I was able
> to make a quick fix to fs/ufs/super.c in order to detect the new magic
> number. I don't think this needs to get into mainline, but hopefully
> this will hit the archives to save anyone else the effort.

Oh, I expect we'll merge it - we're crazy like that.  Thanks.

> I'm assume
> that this number is the same for all installations. It's quite easy to
> find out from ufs_fs.h. The superblock sits 8k into the block device and
> the magic number its 1372 bytes into the superblock struct.
> 
> # dd if=/dev/sda5 skip=$(( 8192 + 1372 )) bs=1 count=4 2> /dev/null | hd
> 00000000  97 26 24 0f                                       |.&$.|
> #
> 
> Here is the patch, please cc any questions or comments as I'm off list.

It would be preferred if you could send us your Signed-off-by: for this
change, please.  It's described in Documentation/SubmittingPatches.

> diff -urN linux-2.6.33.1.orig/fs/ufs/super.c linux-2.6.33.1/fs/ufs/super.c
> --- linux-2.6.33.1.orig/fs/ufs/super.c  2010-05-11 20:07:08.000000000 +0100
> +++ linux-2.6.33.1/fs/ufs/super.c       2010-05-11 21:23:06.000000000 +0100
> @@ -918,6 +918,7 @@
>         sbi->s_bytesex = BYTESEX_LE;
>         switch ((uspi->fs_magic = fs32_to_cpu(sb, usb3->fs_magic))) {
>                 case UFS_MAGIC:
> +               case UFS_MAGIC_BW:
>                 case UFS2_MAGIC:
>                 case UFS_MAGIC_LFN:
>                 case UFS_MAGIC_FEA:
> @@ -927,6 +928,7 @@
>         sbi->s_bytesex = BYTESEX_BE;
>         switch ((uspi->fs_magic = fs32_to_cpu(sb, usb3->fs_magic))) {
>                 case UFS_MAGIC:
> +               case UFS_MAGIC_BW:
>                 case UFS2_MAGIC:
>                 case UFS_MAGIC_LFN:
>                 case UFS_MAGIC_FEA:

Your email client replaces tabs with spaces.  I fixed that up.

> diff -urN linux-2.6.33.1.orig/fs/ufs/ufs_fs.h linux-2.6.33.1/fs/ufs/ufs_fs.h
> --- linux-2.6.33.1.orig/fs/ufs/ufs_fs.h 2010-03-15 16:09:39.000000000 +0000
> +++ linux-2.6.33.1/fs/ufs/ufs_fs.h      2010-05-11 21:20:35.000000000 +0100
> @@ -48,6 +48,7 @@
>  #define UFS_SECTOR_SIZE 512
>  #define UFS_SECTOR_BITS 9
>  #define UFS_MAGIC  0x00011954
> +#define UFS_MAGIC_BW 0x0f242697
>  #define UFS2_MAGIC 0x19540119
>  #define UFS_CIGAM  0x54190100 /* byteswapped MAGIC */

Perhaps we should move these to magic.h.  I'm not sure what benefit
that would provide, really.

--
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/