linux-kernel - Re: [patch for 2.6.26 0/7] Architecture Independent Markers

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 28 Mar 2008 09:40:06 -0400
From:	fche@...hat.com (Frank Ch. Eigler)
To:	Ingo Molnar <mingo@...e.hu>
Cc:	KOSAKI Motohiro <m-kosaki@...es.dti.ne.jp>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [patch for 2.6.26 0/7] Architecture Independent Markers

>> >  NACK-ed-by: Ingo Molnar <mingo@...e.hu>
>> [...]
>> I wonder why nobody doesn't fix this serious problem until now. [...]

Frankly, the "problem" has not yet been established.  Ingo has failed
to respond to Mathieu's analysis of the actual instruction streams,
which cast doubt on Ingo's technique of simply counting bytes.  So
far, neither Ingo nor Mathieu have published *time measurements* to
quantify the actual (as opposed to speculated) costs.

> [...]  furthermore, and because it's Friday again, let me remind
> folks that SystemTap has an even more significant bloat problem: the
> fact that it needs a huge download: [...the dwarf debugging
> information...]

It's a problem, and there are a few improvements under way or being
contemplated:

- compression of the DWARF data to eliminate more duplication
- support for inserting probes only on function entry/exit points
  without debugging data - relying on symbol tables and raw ABI
- a networked service to allow one machine to serve site-wide
  systemtap needs

At the end of the day, lots of information will still need to be
around for those who need to put probes approximately anywhere and to
pull approximately any data out.

> for heaven's sake, we can have 3 years of _full Linux kernel
> history_, with all 87875 commits, with full changelog and
> dependencies and full source code included, packed into a rather
> tight, 180 MB git repository

It may seem counterintuitive to you, but remember that object code is
recreated from scratch new every build, yet source code only gradually
(?)  changes.  Try checking in 3 years' builds of stripped object
files into a git repo.

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