linux-kernel - Re: [GIT] kbuild changes for v3.11-rc1

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: <CA+55aFyVjugxM7cUDWi0ASWttYthCxa6e7X3CADknBcSFxWgew@mail.gmail.com>
Date:	Thu, 11 Jul 2013 10:16:18 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Michal Marek <mmarek@...e.cz>
Cc:	Jan Beulich <JBeulich@...e.com>, dt.tangr@...il.com,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	James Hogan <james.hogan@...tec.com>,
	Christian Kujau <lists@...dbynature.de>,
	Mike Marciniszyn <mike.marciniszyn@...el.com>,
	Nicolas Dichtel <nicolas.dichtel@...nd.com>,
	robert.richter@...xeda.com,
	"Yaakov (Cygwin/X)" <yselkowitz@...rs.sourceforge.net>,
	zzs0213@...il.com,
	Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT] kbuild changes for v3.11-rc1

On Thu, Jul 11, 2013 at 6:54 AM, Michal Marek <mmarek@...e.cz> wrote:
>
> Yeah. It also reveals another bug that we rewrite the kernel.release
> file each time. This patch should fix it, but please do not apply it
> yet:

So I think not rewriting the file is a good thing, but in this case it
would actually have hidden the real bug.

At least for most people. For me, it would have rewritten the file
anyway, because as a normal user I have

  core.abbrev=12

in my ~/.gitconfig, but when running it as root, it will take the
abbrev setting from the git defaults (which I think is 7). So the
content actually *changes* if root generates the version as opposed to
my normal user account.

Of course, that's arguably something we could fix in our localversion
script (by just forcing a particular abbreviation length), but I
actually like how a plain "git describe" (which will use the
user-specified SHA1 abbreviations) matches "uname -r" (which will
obviously take the version from the kernel version file at
build-time). So I'm not convinced that it is wrong for us to just use
the format that the user specified in their gitconfig, even if it does
result in "odd" situations like this where "make kernelrelease" will
then potentially give different output for different users.

> We also run dozens of gcc checks during every make invocation, including
> make install or make help, so there is some room for improvement. But at
> least, these do not write to the source or object tree.

It would be good to try to minimize these kinds of things, for the
simple reason that I'm not at all sure that we necessarily get all the
temporary file security issues right.

Running as little as possible as root is good practice for a very real
reason: there can be very subtle security issues. Let's not worry
about it *too* much, but keeping it in mind is good.

At least for the gcc checking scripts I looked at, we seem to be doing
things safely (ie using pipes instead of temp-files in /tmp).

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