linux-kernel - Laptop shock detection and harddisk protection

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-next>] [day] [month] [year] [list]

Date:	Wed, 10 Sep 2008 18:59:26 +0200
From:	Tejun Heo <tj@...nel.org>
To:	multinymous@...il.com, Elias Oltmanns <eo@...ensachen.de>,
	Thomas Renninger <trenn@...e.de>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	IDE/ATA development list <linux-ide@...r.kernel.org>
Subject: Laptop shock detection and harddisk protection

Hello, all.

Elias has been sending libata/ide shock protection patches[1] and for
libata I think it's only one or two iterations from being included.
The interface is pretty simple, it only has to write timeout values to
sysfs nodes for all disks.

Thomas is now working on implementing shock detection for HP laptops
where the interface is much simpler than the HDAPS one.  Interrupts
for danger imminent and danger over plus control for warning LED.

I browsed a little bit for HDAPS one and it seems all the pieces are
there but scattered.  The latest effort seems tp_smapi which Shem
Multinymous is working on.

So, overall, all the pieces are falling into places but many pieces
are not upstream yet and there also are interface differences for
different detection drivers.  The original hdaps uses polling on sysfs
nodes, the HP thing Thomas is working on is likely to use sysfs +
sysfs_notify_event() and probably another node to control LED.  The
tp_smapi seems to use joystick input device to transfer the data along
all the axises.

So, I think it's about time to decide how to proceed on this
acceleration detection and shock protection thing.

1. How should the shock interface look like?  As we're gonna need
   userland daemon one way or the other, we can use the userland
   daemon to glue all the interfaces but it would be much better to
   have a unified interface.  Although there seem to be several
   different variants, they don't differ all that much and creating a
   new interface every time is painful.  I think we can get by with a
   sysfs interface with notification.

2. If we're gonna unify interface, how much can we unify the backend?
   Some devices are based on polling, others interrupt.  For polling,
   is it better to delegate the whole polling to userland or is it
   better to do some of it in kernel (tp_smapi seems to be doing
   this)?

3. What about the userland daemon?  It would be best to have a unified
   daemon which can handle all instead of one for hdaps and another
   for hp (and so on).  If we can unify the interface, this will be
   much easier.

Thanks.

-- 
tejun

[1] http://thread.gmane.org/gmane.linux.ide/34103
--
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/