linux-kernel - Re: [PATCH 12/13] hrtimer: create a "timer

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]

Message-ID: <a36005b50809140821w2caeb810p431cf5625b0297f5@mail.gmail.com>
Date:	Sun, 14 Sep 2008 08:21:26 -0700
From:	"Ulrich Drepper" <drepper@...il.com>
To:	"Pavel Machek" <pavel@...e.cz>
Cc:	"Arjan van de Ven" <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	dwmw2@...radead.org, drepper@...hat.com, mingo@...e.hu,
	tglx@...x.de
Subject: Re: [PATCH 12/13] hrtimer: create a "timer_slack" field in the task struct

On Mon, Sep 8, 2008 at 7:15 AM, Pavel Machek <pavel@...e.cz> wrote:
> Ok, so select()/poll() may default to non-zero slack for legacy apps.

That's the goal.

> Yes, it is a great advantage, but it feels like a hack. Maybe it is
> better done with LD_PRELOAD or something?
>
> I'd certianly want the applications to specify slack themselves in
> like 10 years.

LD_PRELOAD is not a solution.  LD_PRELOAD always has been and always
will be a hack.  You use it to work around problems or to test
something.  Nothing else.

LD_PRELOAD and other variables are ignored in security-relevant
contexts and environments are cleared in many situations.  Sure, you
could use /etc/ld.so.preload but that works around only one problem.
Furthermore, there is a significant cost associated with preloading.
There are additional files to be loaded and it disables prelinking.

The prctl() way plus a default non-zero value is the best way for
legacy apps.  And you'll hopefully get your wish that apps will take
fate into their own hand by specifying the slack themselves.  Arjan's
proposal also introduces new poll/select-like interface which take the
additional slack value (at least that's what we discussed before).

I'm strongly opposed to using LD_PRELOAD.  And I think requiring the
libc implementation of select/ poll, ... etc to wrap around the new
interfaces which take the slack and determine the slack at userlevel
(by reading some file) is too expensive.  It's one little value per
process (group) to be kept by the kernel.  That's not much.
--
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/