linux-kernel - Re: [PATCH RFC]: New termios take 2

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: <1157887240.2977.147.camel@pmac.infradead.org>
Date:	Sun, 10 Sep 2006 12:20:40 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH RFC]: New termios take 2

On Sun, 2006-09-10 at 12:15 +0100, Alan Cox wrote:
> Kernel headers are not intended for user space. In this case the struct
> termios presented by glibc already differs from the termios presented by
> the kernel so the problem doesn't arise at all.

Please note that we are moving away from the mindless repetition of that
phrase, and moving towards a system where we actually _mean_ it.

If you really don't want asm/term{bit,io}s.h to be visible in userspace,
then the way to express that is to provide a patch to
include/asm-generic/Kbuild which removes them from the export.

I don't think I agree -- I think these files _do_ provide part of the
kernel<->user ABI and should be kept. You're right that userspace in
_general_ shouldn't be touching them -- as I said, it's only really the
C libraries that are important here. As long as _they_ get it right when
built against the headers with your changes, we're fine.

But I don't think it's realistic to suggest that C libraries should be
built without access to our asm/term{bit,io}s.h at all. However, I'm
only really responsible for the new export _mechanism_ -- I'm not going
to impose policy except when people like Andi do stupid things and
sneakily send private patches to undo fixes I've already made.

So if you want to unexport those headers and make sure the C libraries
work like that, please do go ahead -- but don't just _say_ it, _do_ it
-- and please do make sure that at _least_ glibc still builds
afterwards.

-- 
dwmw2

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