linux-kernel - Re: Linux kernel - Libata bad block error handling to user mode program

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: <f875e2fe1003040733h20d5523ex5d18b84f47fee8c7@mail.gmail.com>
Date:	Thu, 4 Mar 2010 10:33:52 -0500
From:	foo saa <foosaa@...il.com>
To:	Mark Lord <kernel@...savvy.com>
Cc:	Greg Freemyer <greg.freemyer@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org,
	Jens Axboe <jens.axboe@...cle.com>, linux-mm@...ck.org
Subject: Re: Linux kernel - Libata bad block error handling to user mode 
	program

I am using 4k aligned buffers for writing and reading.

Kernel / driver catches the error during the write cycle and I can get
the error messages about the media being bad or sector i/o errors. But
it is not propagated to the program and write always passes (even in
the case of the device being out of control. (i.e., the device fails
to respond to any further open / read / write queries and inaccessible
from the core). Isn't the error has to be notified to the program that
makes the call?

Reading is a completely different scenario and I am disabling the
read-ahead cache completely with fadvise call.

hdparm is good, but I don't want to use the internal ATA SECURE ERASE
because I can never get the amount of bad sectors the drive had.

On Thu, Mar 4, 2010 at 9:41 AM, Mark Lord <kernel@...savvy.com> wrote:
> On 03/04/10 09:17, Greg Freemyer wrote:
> ..
>>
>> I think / suspect your major problem is you say above that you use a
>> 512-byte buffer to wipe with.  The kernel is using 4K pages.  So when
>> you write to a 4K section of the drive for the first time, the kernel
>> implements read-modify-write logic.
>>
>> Your i/o failures are almost certainly on the read cycle of the above,
>> not the write cycle.  You need to move to 4K buffers and you need to
>> ensure your 4K writes are aligned with how the kernel is working with
>> the disk.  ie. You need your 4K buffer to perfectly align with the
>> kernels 4K block handling so you never have a read-modify-write cycle.
>
> ..
>
> You'll also need to disable Linux read-ahead for the drive,
> or it may try reading beyond even the 4KB block.
>
> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough ???
>
> Cheers
>
--
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/