linux-kernel - ieee1394 feature needed: overwrite SPLIT

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:	Fri, 12 Jan 2007 12:42:37 +0100
From:	Philipp Beyer <philipp.beyer@...iedvisiontec.com>
To:	LKML <linux-kernel@...r.kernel.org>
Subject: ieee1394 feature needed: overwrite SPLIT_TIMEOUT from userspace

Hi,

I'm investigating an unwanted behaviour of our firewire devices in 
connection with the ieee1394 kernel module.

The problem is caused by a non standard-conform behaviour of our
devices. Anyway, changes on the device-side dont seem to be the
best solution, so I'm looking for a workaround in terms of a
kernel patch.

The problem:
Our devices exceed the SPLIT_TIMEOUT for write requests in some
situations, where write accesses to the devices flash memory are 
triggered. The SPLIT_TIMEOUT could be adjusted as it's part of the 
CSR layout, but the longest interval possible is 8 seconds. We need
a substantial longer interval to assure failure-free operation.
(the maximum timeout needed may be around 120 seconds)

The presumed solution:
These long timeouts are only needed in a few rare situations like
writing user presets to flash or firmware updates. As far as I've
examined the kernel code it would be the best thing to have a
function (ioctl?) accessible from userspace that overwrites the
stored SPLIT_TIMEOUT for a certain connected device. This way
there should not be any interferences in case of normal operation.
Until (rare) write accesses to the flash memory are performed, a
reasonable short timeout could be used.

Since I don't have any real experience in kernel hacking yet,
this should be interpreted as a feature request at first:
If the described feature is easy to implement I would appreciate
if someone could do this.

Otherwise I'm confident that I'm able to write a patch on my own.
In this case the critical part would be to meet the standards
of the kernel community, since we would like to have the patch
included in the mainline.

Therefore I'm also interested in any kind of advices about how
to realize an appropriate patch.

Thanks,

Philipp Beyer

Software Development
Allied Vision Technologies

-
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/