linux-kernel - Re: is there any Hard-disk shock-protection for 2.6.18 and above?

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:	Sun, 10 Dec 2006 02:02:26 +0100
From:	Elias Oltmanns <eo@...ensachen.de>
To:	Pavel Machek <pavel@....cz>
Cc:	Jens Axboe <jens.axboe@...cle.com>,
	Christoph Schmid <chris@...lagmichtod.de>,
	linux-kernel@...r.kernel.org
Subject: Re: is there any Hard-disk shock-protection for 2.6.18 and above?

Hi Pavel,

Pavel Machek <pavel@....cz> wrote:
>> >> +module_param_named(protect_method, libata_protect_method, int, 0444);
>> >> +MODULE_PARM_DESC(protect_method, "hdaps disk protection method  (0=autodetect, 1=unload, 2=standby)");
>> >
>> > Should this be configurable by module parameter? Why not tell each
>> > unload what to do?
[...]
>> > Is /sys interface right thing to do?
>> 
>> Probably, you're right here. Since this feature is actually drive
>> specific, it should not really be set globally as a libata or ide-disk
>> parameter but specifically for each drive connected. Perhaps we should
>> add another attribute to /sys/block/*/queue or enhance the scope of
>> /sys/block/*/queue/protect?
>
> Certainly better than current solution. Or maybe ioctl similar to wat
> hdparm uses?
> 							Pavel

I'm not quite sure what you have in mind wrt ioctls. I'm still
convinced that the administrator should take a conscious decision when
forcing an idle immediate with unload feature on a drive which doesn't
announce this capability according to the specs. This is because I
have no idea as to how drives might react if they don't support it.
Perhaps we should consult linux-ide on this topic.

Anyway, this is the reason why I favour the sysfs approach. The
decision can be made, for instance, in a udev rule during device
setup.

So, here is a patch in which your remarks and suggestions have been
incorporated. Additionally, I've added the requested kernel doc file
and another sysfs attribute called protect_method. The usage of this
attribute is described in Documentation/block/disk-protection.txt.

Patch applies to 2.6.19.

Signed-off-by: Elias Oltmanns <eo@...ensachen.de>
---
 Documentation/block/disk-protection.txt |   79 +++++++
 block/ll_rw_blk.c                       |  224 ++++++++++++++++++++++
 drivers/ata/libata-scsi.c               |   29 ++
 drivers/ide/ide-disk.c                  |  142 +++++++++++++
 drivers/ide/ide-io.c                    |   14 +
 drivers/scsi/scsi_lib.c                 |  163 ++++++++++++++++
 include/linux/ata.h                     |    1
 include/linux/blkdev.h                  |   14 +
 include/linux/ide.h                     |    1
 9 files changed, 667 insertions(+)

View attachment "hdaps_protect-2.6.19-2.patch" of type "text/x-patch" (26126 bytes)