Write Blocker for Linux flips upon encountering bad sectors

Hi,

I ran "sudo udevadm monitor", got the following

KERNEL[439.808031] change /devices/pci000000/0000001f.2/ata6/host6/target600/6000/block/sdb (block)

UDEV[439.833507] change /devices/pci000000/0000001f.2/ata6/host6/target600/6000/block/sdb (block)

For "dmesg | tail", got the following

Sense Key Medium Error [current] [descriptor]
Descriptor sense data with sense descriptors (in hex)
72 03 …………….
sd 6000 [sdb]
Add. Sense Unrecovered read error - auto reallocate failed
sd 6000 [sdb] CDB
Read(10) 28…………….
end_request I/O error, dev sdb, sector 40010
ata6 EH complete

Okay, thank you. Does this failing drive have a partition table (i.e. do you see /dev/sdb1 after attaching the drive and before trying to image it)? Is this a SATA or PATA drive?

Hi,

Yah can see the partitions and it is a SATA disk.

Regards

The problem is in the kernel, not in the udev. My guess is that the kernel is revalidating the device on I/O error, thus resetting its r/o flag to zero. I think we can fix this, but I need you to do the following first

1. Run "sudo udevadm monitor –property >> log.txt".
2. Reproduce the issue again.
3. Open the "log.txt" file in text editor and search for any lines starting with "DISK_RO=". Do you see them?

Hi,

Yes I Could see it. Twice

DISK_RO=0
DISK_RO=0

I also tested in the newly released Kali Linux 2.0, seems to have the same flipping occurrence. As you have mentioned could be the kernel issue.

Regards.

Hi,

Yes I Could see it. Twice

DISK_RO=0
DISK_RO=0

I also tested in the newly released Kali Linux 2.0, seems to have the same flipping occurrence. As you have mentioned could be the kernel issue.

Regards.

1. Place this to /usr/sbin/wrtblk-ioerr
#!/bin/sh

# Mark all child block devices as read-only
syspath=$(echo /sys/block/"$bdev"/*/dev)
[ "$syspath" = "/sys/block/"$bdev"/*/dev" ] && exit
for child in $syspath; do
dir=${child%/*}
partition=${dir##*/}
[ -b "/dev/$partition" ] || continue
blockdev --setro "/dev/$partition" || logger "wrtblk blockdev --setro /dev/$partition failed!"
done
2. Make this file executable "chmod +x /urs/sbin/wrtblk-ioerr".
3. Add the following line to your udev rule
ACTION=="change", SUBSYSTEM=="block", KERNEL!="ram*", ENV{DISK_RO}=="0", RUN+="/usr/sbin/wrtblk-ioerr %k"
4. Try to reproduce the issue again.

Wow,

Now it doesn't flips! Thanks!!

Sorry I am a noob in this area, just for clarification.

The new udev rule, actually checks whether the status changes and if it changes it will run the shell script which will reset the status to RO only? Am I right?

Am I write to say udev rules takes priority over changes initiated by kernel?

Thanks

The new udev rule, actually checks whether the status changes and if it changes it will run the shell script which will reset the status to RO only? Am I right?

Yes. And if you execute this rule before any other udev rule (like LVM or RAID activation rules), nothing bad will happen. That's why you need to prefix your rule with "01-". According to the man page of udev

The udev rules are read from the files located in the default rules
directory /lib/udev/rules.d/, the custom rules directory
/etc/udev/rules.d/ and the temporary rules directory
/run/udev/rules.d/. All rule files are collectively sorted and
processed in lexical order, regardless of the directories in which they
live. However, files in /etc/udev/rules.d/ take precedence over files
with the same name in /lib/udev/rules.d/; this can be used to ignore a
default rules file if needed.

Am I write to say udev rules takes priority over changes initiated by kernel?

The kernel marks a device and all its partitions as read-write and sends the uevent message to a userspace program (i.e. udev). This program finds out that the r/o status of a device was changed to 0 (r/w) and initiates the process of marking a device and all its partitions as read-only.

PS. Take a look at https://github.com/msuhanov/Linux-write-blocker

Thanks for the explanation!!

Hi,

But I noticed something by implementing this.

I tried to acquire using dc3dd command (with hash calculation) with the udev rules implemented from a disk that contains bad sectors.

Now it doesn't flips, but at the end of the process the hash doesn't match.

In the log file, it shows the input hash but for output hash it specify "Input/Output error".

Whereas when I set the source as RW and do acquisition, at the end of it the hash matches (both the input and output hash are the same).

Does this mean that when bad sector is encountered the system tries to set the the source as RW actually writes zeros into the bad sector and calculates the hash subsequently?

But now with udev rules in place which forces the source to be always RO, it cannot write zeros to the bad sectors thus subsequently it fails the hash calculation?

Thanks

Hi,

But I noticed something by implementing this.

I tried to acquire using dc3dd command (with hash calculation) with the udev rules implemented from a disk that contains bad sectors.

Now it doesn't flips, but at the end of the process the hash doesn't match.

In the log file, it shows the input hash but for output hash it specify "Input/Output error".

Whereas when I set the source as RW and do acquisition, at the end of it the hash matches (both the input and output hash are the same).

Does this mean that when bad sector is encountered the system tries to set the the source as RW actually writes zeros into the bad sector and calculates the hash subsequently?

But now with udev rules in place which forces the source to be always RO, it cannot write zeros to the bad sectors thus subsequently it fails the hash calculation?

Thanks

dc3dd is always replacing bad sectors with null bytes in-memory and in an output image (it can't just skip unreadable areas, because this will misalign partitions and file system data), dc3dd has zero knowledge about udev rules on a system and the write policy set on a drive being acquired should not change anything. And dc3dd is not expected to write anything to a source drive.

Please, do the following
1) install hashdeep (http//sourceforge.net/projects/hashdeep/);
2) run "hashdeep -p 512 -c md5 image-1.raw | cut -d ',' -f 2 > 1.txt" (where "image-1.raw" is an image file from the first acquisition, this will produce a huge output file);
3) run "hashdeep -p 512 -c md5 image-2.raw | cut -d ',' -f 2 > 2.txt" (where "image-2.raw" is an image file from the second acquisition);
4) run "diff 1.txt 2.txt > diff-1-2.txt";
5) paste the contents of the "diff-1-2.txt" file here, if it's not too large (but don't do this if you consider hashes of sectors to be private!).