linux-kernel - Re: 2.6.18 Headers

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: <787b0d920607161222o55cd8837g6545bfd00e50d452@mail.gmail.com>
Date:	Sun, 16 Jul 2006 15:22:01 -0400
From:	"Albert Cahalan" <acahalan@...il.com>
To:	"Albert Cahalan" <acahalan@...il.com>,
	"Kyle Moffett" <mrmacman_g4@....com>, dwmw2@...radead.org,
	arjan@...radead.org, maillist@...55.com, ralf@...ux-mips.org,
	linux-kernel@...r.kernel.org, davem@...emloft.net
Subject: Re: 2.6.18 Headers - Long

On 7/16/06, Russell King <rmk+lkml@....linux.org.uk> wrote:
> On Sun, Jul 16, 2006 at 02:38:45PM -0400, Albert Cahalan wrote:
> > On 7/16/06, Kyle Moffett <mrmacman_g4@....com> wrote:
> > >On Jul 15, 2006, at 17:09:28, Albert Cahalan wrote:
> >
> > >You realize that on a couple architectures it's fundamentally
> > >impossible to get atomic ops completely in userspace, right?
> >
> > Sure. Those architectures don't need to drag down the rest.
> > Plenty of headers are only exported for some architectures.
>
> Wrong perspective.  The problem is that they may _appear_ to work as
> described, but not actually work in the intended way.  That's a bug,
> and it's a _hard_ bug to locate.

Again:

Plenty of headers are only exported for some architectures.

In other words, for all architectures where things work.

> > (Well actually, such architectures could just give apps a
> > writable flag to disable the scheduler -- this is acceptable
> > for the embedded things these architectures are used for.
>
> Cloud cuckoo land.  In the embedded world, there are folk still want
> to have the security aspects as well.  Moreover, there are far more
> folk who do _NOT_ want to have things like "disable the scheduler" -
> think the realtime folk.

Now you are really wrong. :-)

The Linux system I saw using this hack was carefully tuned
for hard real-time performance. Latency was a few dozen
microseconds. Disabling the scheduler essentially put you
at the highest SCHED_FIFO; aside from that there was
working priority inheritance for both kernel and user code.
The real-time folk love this kind of thing.

Anyway, it's fine to just not let ARM export the header.

> > It's not as if the app developers would care to support
> > those architectures anyway.
>
> That's actually more of a reason to take away the toys they shouldn't
> be playing with in the first place - the only reason these (wrong)
> interfaces are being used is because they're easily accessible.

No. The normal interfaces are dreadful.

App developers will just cut-and-paste the i386 kernel
code if you take away the header files. They do that
often enough already. So all you succeed in doing is
eliminating any hope of portability to ppc and similar.
This is not an improvement.
-
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/