linux-kernel - Re: [PATCH V4 8/9] perf buildid-cache: add ability to add kcore to the cache

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: <87k3hoky4x.fsf@sejong.aot.lge.com>
Date:	Tue, 08 Oct 2013 16:41:34 +0900
From:	Namhyung Kim <namhyung@...nel.org>
To:	Adrian Hunter <adrian.hunter@...el.com>
Cc:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel@...r.kernel.org, David Ahern <dsahern@...il.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Jiri Olsa <jolsa@...hat.com>, Mike Galbraith <efault@....de>,
	Paul Mackerras <paulus@...ba.org>,
	Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH V4 8/9] perf buildid-cache: add ability to add kcore to the cache

On Mon,  7 Oct 2013 09:50:17 +0300, Adrian Hunter wrote:
> kcore can be used to view the running kernel object code.
> However, kcore changes as modules are loaded and unloaded,
> and when the kernel decides to modify its own code.
> Consequently it is useful to create a copy of kcore at a
> particular time.  Unlike vmlinux, kcore is not unique
> for a given build-id.  And in addition, the kallsyms
> and modules files are also needed.  The tool therefore
> creates a directory:
>
> 	~/.debug/[kernel.kcore]/<build-id>/<YYYYmmddHHMMSShh>
>
> which contains: kcore, kallsyms and modules.

Hmm..  I think the problem is that the kallsyms and kcore also have
module information and the build-id of kernel can identify the core
kernel part only.  So why not splitting modules from kcore and kallsyms?

As the modules have their own build-id, we can extract module info from
kcore and kallsyms and put them under ~/.debug/[module]/<build-id>.
While at it, we can even synthesize symbol table and inject it into the
module kcore and get rid of the module kallsyms file.

This way, we can identify all binaries using build-id only, no?

>
> Note that the copied kcore contains only code sections.
> See the kcore_copy() function for how that is determined.
>
> The tool will not make additional copies of kcore if there
> is already one with the same modules at the same addresses.
>
> Currently, perf tools will not look for kcore in the cache.
> That is addressed in another patch.
>
[SNIP]

> +static int build_id_cache__kcore_buildid(const char *proc_dir, char *sbuildid)
> +{
> +	char root_dir[PATH_MAX];
> +	char notes[PATH_MAX];
> +	u8 build_id[BUILD_ID_SIZE];
> +	char *p;
> +
> +	strlcpy(root_dir, proc_dir, sizeof(root_dir));
> +
> +	p = strrchr(root_dir, '/');
> +	if (!p)
> +		return -1;
> +	*p = '\0';
> +
> +	snprintf(notes, sizeof(notes), "%s/sys/kernel/notes", root_dir);

Please use scnprintf() rather than snprintf().  I can see them in other
places (and on other patches) too.

Thanks,
Namhyung

> +
> +	if (sysfs__read_build_id(notes, build_id, sizeof(build_id)))
> +		return -1;
> +
> +	build_id__sprintf(build_id, sizeof(build_id), sbuildid);
> +
> +	return 0;
> +}
--
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/