linux-kernel - Re: RFC -- /proc/patches to track development

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: <Pine.LNX.4.61.0611150238570.1046@yvahk01.tjqt.qr>
Date:	Wed, 15 Nov 2006 02:46:11 +0100 (MET)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	Marty Leisner <leisner@...hester.rr.com>
cc:	linux-kernel@...r.kernel.org
Subject: Re: RFC  -- /proc/patches to track development 

>From: Marty Leisner <leisner@...hester.rr.com>
>Subject: RFC  -- /proc/patches to track development 
                  ^^^^^

Wrong place. Really. (And I do not think /sys is a better one either. 
But let others speak up.)

>I always want to know WHAT I'm running (or people I'm working with

`uname -a`?

>are running) rather than  "guessing" ("do you have the most current 
>patch" "I think so")
>
>I've been a proponent of capturing .config information SOMEPLACE where
>you can look at it at runtime...(it took a while but its there now).

/proc/config,gz?

>In /proc/patches there would be a series of comments (perhaps including
>file, date and time) of various patches you want to monitor.  

Wastes nonswappable memory.

>It would be enabled by something like
>
>in file foo.c:
>PATCH_COMMENT("this enables the foo feature");
>
>
>In membar.c:
>PATCH_COMMENT("go to the bar on saturday");
>...
>PATCH_COMMENT("watch how much you drink");
>
>
>and in /proc/patches:
>
>foo.c: compiled <date> <time>:this enables the foo feature
>membar.c: compiled <date> <time>:go to the bar on saturday
>member.c: compiled <date> <time>:watch how much you drink
>
>There would be a Kconfig flag whether or not to enable this (i.e.
>production kernels would not need it,
>hacked kernels would, it could always be there if you're willing to
>increase the footprint).

Reasonable. However, I would prefer that PATCH_COMMENT() evaluates to a 
string that is included in the module only (think MODULE_DESCRIPTION) 
and is not loaded during modprobe. Instead, modinfo your 
/lib/modules/`uname -r` tree and grep for your PATCH_COMMENT lines. Hey, 
that's even in userspace - no memory wasted.

>Instead of looking for aberrant behavior to identify patches, you could easily
>see things with cat.

Can you define patch? IMO, if you run a normal, mm, or git kernel, you 
usually find -mm or -git in the `uname -r` output. Of course there is 
also some development going on between -gitA and -gitB, but most people 
seem to keep together what they have patched.

>Seems very easy and has high ROI if you need to track patched kernels locally.

Patched by whom? (Tier-1 kernel developers (mainline, mm and those who 
run a tree on git.kernel.org), or Tier-2+ (Distro vendors))

	-`J'
-- 
-
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/