linux-kernel - Re: [PATCH 2/4] libata: Implement disk shock protection support

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:	Fri, 12 Sep 2008 12:15:22 +0200
From:	Elias Oltmanns <eo@...ensachen.de>
To:	Tejun Heo <htejun@...il.com>
Cc:	Valdis.Kletnieks@...edu, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	Jeff Garzik <jeff@...zik.org>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] libata: Implement disk shock protection support

Tejun Heo <htejun@...il.com> wrote:
> Valdis.Kletnieks@...edu wrote:
>> On Thu, 11 Sep 2008 15:01:00 +0200, Tejun Heo said:
>
>>> Ah.. just one more thing.
>>>
>>> I think it would be easier on the application if the written timeout
>>> value is cropped if it's over the maximum instead of failing the
>>> write.
>> 
>> Which is better, failing the write so the application *knows* there is a
>> problem, or letting the application proceed with a totally incorrect idea of
>> what the value is set to?
>
> It depends.  As -EINVAL either results in program failure or no
> protection for the event.
>
>> For instance, what happens if the program tries to set 100, it's silently
>> clamped to 10, and it then tries to set a timer for itself to '90% of the
>> value'?  It might be in for an unpleasant surprise when it finds out that
>> it's overshot by 81....
>
> Hitting the limit would be a pretty rare occasion and which way we go
> it's not gonna be too pretty.  e.g. Let's say a program calculates
> timeout according to some algorithm which 99.9% of the time stays in
> the limit but once in the blue moon hits the ceiling.  Given the
> characteristics of the problem and very high limit value, I think it's
> better to have cropped value.
>
> How about returning -OVERFLOW while still setting the timeout to the
> maximum?

Yes, that makes sense. I'll take care to document it that way:
-EINVAL for values < -2, -EOVERFLOW for values > 30000.

Once we have smoothed things out wrt the ide patch, I'll repost the
whole series against a recent linux-next tree, so it can be queued up
for 2.6.28. By the way, the ide patch I've just posted does pretty much
what libata should be aiming for in the long run. Hopefully, it'll work
out as expected. Anyway, I'm really grateful to Bart and you for holding
my hand so patiently with all this.

Also, I'll backport the patches to 2.6.27 and make appropriate changes
to hdapsd, so we can get feedback from a wider range of testers. Since
there has been no comment from Jeff as yet, I'll wait with that until
the patches have been merged though.

Regards,

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