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-next>] [day] [month] [year] [list]
Date:	Thu, 6 Oct 2011 23:50:46 +0200
From:	Jan Kara <jack@...e.cz>
To:	Ashish Sangwan <ashishsangwan2@...il.com>
Cc:	jack@...e.cz, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, linkinjeon@...il.com
Subject: Re: UDF alternate anchor block detection

  Hello,

On Fri 30-09-11 11:02:34, Ashish Sangwan wrote:
> While mounting UDF media, when the primary AVDP is not found at block 256,
> UDF code tries to read-in the alternate AVDP.
> In the function udf_find_anchor, udf_scan_anchors is called 3 times, where
> each call to udf_scan_anchors read 12 blocks.
> In case there is no alternate AVDP stored, a total of 36 blocks are read
> before mount fails - causing time delay for Mount Failure.
> 
> After first call to udf_scan_anchors and before the second call there is
> varconv conversion, for the older drivers, which skips 7 blocks after every
> 32 blocks. What are these older drivers? Do we still require this code?
  Frankly, I don't know what are these older drives. The code has been like
this when I started maintaining it and I didn't want to introduce
regressions so I kept the varconv code in.

> After varconv conversion, why is there a third call to udf_scan_anchors? In
> the 1st call and 3rd call to udf_scan_anchors, exactly same blocks are read,
> so this 3rd call seems to be redundant.
  This is not true - the second call uses
udf_variable_to_fixed(sbi->s_last_block) as the last block on the media
while the third call uses sbi->s_last_block as the last block on the media
(both these scans are performed with varconv enabled). Again I have not
seen a drive / medium where this would be needed but I believe original
author had some reason to put the code in.

I agree that the anchor searching code is a pain but that's how the
standard is defined...

> I suggest this modified code for udf_find_anchor :-
> lastblock =
> udf_scan_anchors(sb,udf_variable_to_fixed(sbi->s_last_block),fileset);
>         if (lastblock)
>                 goto out;
>          else {
>                 /* VARCONV didn't help. Clear it. */
>                 UDF_CLEAR_FLAG(sb, UDF_FLAG_VARCONV);
>                 return 0;
>         }
> 
> Please give your opininon to these 2 above points. If the code change seems
> relevant than I can make patch for it.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ