Status 2009-02-02
by Petr Machata
= Work done last week:
* Time spent on elfutils: ~80%
* Tweaks and small fixes, improving the logic in places.
* First high-level check: ranges/aranges mismatch
* Checking ranges in .debug_ranges and .debug_loc: that there is
a section for the range, the the range doesn't cross section boundaries,
that there are no overlaps (in .debug_ranges). It originally also
checked .text coverage, but that's now turned off.
* Validate REL/RELA sections (in isolation, without regard to
other sections).
= Work scheduled for this week:
* Expected time spent on elfutils: 50-80%.
* Relocations. Some half-baked code is in the repository
already, but it's missing features and is probably buggy. It's also
progressing slower than I'd like, the landscape is less familiar than I
thought it would be. But I think I'll be able to get it done by tomorrow.
* With a bit of luck, I may get around to start hacking on
expected-trees high level check. (Planning this arbitrarily, because
Mark Wielaard asked me about the low-pc-less DW_TAG_label last week.)
* Or maybe do a bit of C++ification, even though I would have to
fix a temporary solution for all the X-to-string tables. But that's
really a quick routine task.
* Still didn't get around to go through anomalies we've found,
leaving it for next coding-quota overrun.
PM
14 years, 7 months
Status 2009-02-16
by Petr Machata
= Work done last week:
* Time spent on elfutils: ~80%
* Relocations. Checking .debug_info, .debug_loc, .debug_ranges.
Went through the "dwarflint relocs" e-mail that Roland posted a month
ago, and everything that he mentioned should be implemented.
** Relocations are checked for structural sanity upfront, and
if sound, are sorted in-place and checked linearly as described in that
mail. If not sound, that relocation section is ignored.
** Relocations that aren't aligned with some relocatable datum
are marked as "mismatched". When two relocations are applicable to the
same datum, the first is applied, and the following ones are marked as
mismatched.
* Couple fixes, better diagnostics in several places.
= Work scheduled for this week:
* Expected time spent on elfutils: 50-80%.
* Expected-trees high level check.
* Still didn't get around to go through anomalies we've found,
leaving it for next coding-quota overrun. (Leaving this in TODO so that
it keeps me reminding that I should do it.)
PM
14 years, 7 months
0.140
by Roland McGrath
I think we should push out 0.140 more or less immediately because
of the libelf regression in 0.139 that breaks prelink (and maybe
everything else?). I did test builds based on 7ee70eb.
I'll be out this afternoon and then on again later tonight to do the Fedora
release work if you've done git tag -s, make distcheck, gpg -b tarball by then.
Thanks,
Roland
14 years, 7 months
relocations in .debug_loc, .debug_range
by Petr Machata
Hi,
I'm wondering about how to determine if the address pair read from
loclist is terminating the sequence. When no relocations are in effect,
that's easy: (0,0) is the terminal. But with relocations? Currently
it's considered a terminal if it's (0,0), and neither of the two
addresses was relocated. Is that right?
PM
14 years, 7 months
Adding a Cryptographic Signature to a Linux Kernel Module
by Dave Brolley
Hi,
I'm working on a compilation server for Systemtap
(http://sources.redhat.com/systemtap). This server analyzes and compiles
Systemtap scripts and returns the resulting kernel module (.ko) to the
client. We would like to have the server cryptographically sign the
resulting module for security reasons (tampering) and also for
certification reasons. This would allow a local sysadmin to authorize
the loading of modules created by a given server on his system, provided
that certain restrictions are met.
We are considering an idea proposed by Roland McGrath in which the
server would use NSS libraries to create the signature of the module and
then add that signature to a special section of the module using
elfutils. The client would then extract (remove) the signature and use
it to verify the original module against a local certificate database.
Roland suggested during a Red Hat Systemtap meeting that there is a
"right way to do this" and that he had some ideas, but he also suggested
starting a public discussion for additional input.
So, if you have ideas, comments, concerns about the "right way" of
implementing this plan or have a better idea then, please, let's talk
about it.
Dave
14 years, 7 months
elfutils status 2009-1-9
by Roland McGrath
Last week:
Actual time on elfutils: 10%
* minor tweaks and fritter
This week:
Expected time on elfutils: 10%
* review
* RHBZ#484623
* 0.140 release soon with RHBZ#484946 fix
14 years, 7 months
core grokking bug, RHBZ#484623
by Roland McGrath
Brain dump wrt https://bugzilla.redhat.com/show_bug.cgi?id=484623
It is minor but can be fixed with some thought.
Dumping brain state since I won't get to it right now.
I removed (45c01cd4) the assert, since it was depending on a confluence of
guesses never producing anomalies. But the underlying cause is just masked
(well, shown in anomalous output) now and still should be fixed.
Case is a core file without partial-segments dumps, so using:
unstrip -n -e exec --core core
Relevant core phdrs:
LOAD 0x001000 0x0000000000400000 0x0000000000000000 0x000000 0x001000 R E 0x1000
LOAD 0x001000 0x0000000000600000 0x0000000000000000 0x001000 0x001000 RW 0x1000
Those are from the tiny binary:
LOAD 0x000000 0x0000000000400000 0x0000000000400000 0x000904 0x000904 R E 0x200000
LOAD 0x000908 0x0000000000600908 0x0000000000600908 0x000224 0x000240 RW 0x200000
This one is ET_EXEC so we could be jiggering differently by assuming
absolute addresses. The dwfl_segment_report_module logic treats ET_EXEC
and ET_DYN the same in its guesstimation. I think it's good to keep that
because a) a tiny DSO would have the same issue as this case and b)
an ET_EXEC in an image might be an odd use like a Linux kernel (in a vmcore),
which is effectively ET_DYN sometimes (i.e. p_vaddr not really absolute).
dwfl_segment_report_module sees nothing at 0x400000 because the text is
entirely elided, so we're in the call starting its search at the 0x600000
segment. This is actually the second LOAD with offset aligned== 0, but we
think it's the first. Hence:
0x400000+0x200b48 - /home/roland/redhat/tmp/dl3 -
0x600000+0x201000 - . - [exe]
because the [exe] should have been seen to start at 0x400000.
I'm thinking the way to solve this involves looking if the preceding
segment has no module and precedes immediately, to decide the current
segment is really the later LOAD of 0, not the earlier one.
Needs more thought.
Thanks,
Roland
14 years, 7 months
get a PC from a label
by Stan Cox
Can you reliably, with regard to optimization, get the pc for a
DW_TAG_label that does not have a DW_AT_low_pc associated with it? For
instance doing something like:
dwarf_getsrclines
for each line until a close match
dwarf_onesrcline
dwarf__lineno
dwarf_lineaddr to get its address
14 years, 7 months
Status 2009-02-02
by Petr Machata
= Work done last week:
* Time spent on elfutils: ~80%
* Fix 10-byte LEB128
* Check that each CU is referenced only from one pub* section
* Match the way dwarflint reports offsets with the way elfutils
does it, so that it's easily possible to look up DIEs, CUs, etc. in
readelf output using their offsets.
* Check that the base address selection entry changes base address.
* Validate .debug_ranges. Detour via sequential reading that
turned out to be unviable. Check that .debug_loc and .debug_ranges
entries cover non-zero range (or are these legitimate artifacts?).
* Check that each rangelistptr is aligned to CU's address_size
* Do detailed validation of several location expression opcodes
- DW_OP_bra and DW_OP_skip: that they don't overrun or underrun
opcode buffer, and that their destination address is aligned with the
beginning of some DIE.
- DW_OP_const8[us]: that they don't appear in 32-bit CUs
- DW_OP_const[us], DW_OP_deref_size, DW_OP_plus_uconst: that in
32-bit CUs, their argument fits on 32-bit stack.
* Split into C and C++ part. Eventually, I may get around to
C++-ify all the C-only GNUisms I've sprinkled across dwaflint, but right
now having two "halves" (high-level C++, low-level C) makes more sense.
* Validate .debug_aranges overlaps, uncovered parts, etc.
Currently this is done in perhaps too generous a way: the code does
coverage analysis of ony AX section. Except if .init, .fini. or .plt
are not covered at all, it doesn't flag it as an error. Is it better to
assume that all "interesting" code will be in .text? It would simplify
the analysis code a little.
* Update the wiki with current status.
= Work scheduled for this week:
* Expected time spent on elfutils: 50-80%.
* .debug_ranges, .debug_loc range analysis (coverage, overlaps)
* I think I might actually get around to relocs this week.
* I didn't get around to go through anomalies we've found, leaving
it for next coding-quota overrun.
PM
_______________________________________________
elfutils-devel mailing list
elfutils-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/elfutils-devel
14 years, 7 months
Uncovered NOP runs
by Petr Machata
Hi,
.debug_arange analysis shows that there's a lot of holes in .text.
Turns out these are NOP runs (for alignment purposes, I guess). First,
is it OK for the producer to leave NOP runs alone? If yes, dwarflint
shouldn't warn about it, but then there is a problem of how to detect this.
I think we can assume that the compiler actually emits literal "NOP"
instructions for padding purposes (i.e. not one of these contraptions
that look like they do something). But most of the time, we won't even
see contents of .text, will we? We are dealing with stripped
debuginfo-only files. Or are we going to do our debuginfo
transformation business on full files?
PM
14 years, 7 months