[09:49] <apw> smb_tp, i presume the launchpad bug robot only closes bugs listed in the changelog
[09:50] <smb_tp> Only those that have a matching But: # entry there
[09:50] <smb_tp> s/But/Bug/
[09:51] <apw> so any bugs which arn't duplicates bug fixed by the same fixes basically have to be manually handled
[09:52] <smb_tp> yes, that is correct.
[09:52] <apw> cool thanks
[09:53] <smb_tp> We might try for future ones whether comma separated lists work. Never had that before
[09:54] <mne> Hi. Where can I see which patches have been applied to the ubuntu kernel ? Also, is there a way to see the memory segments the kernel is using ?
[10:09] <amitk> mne: in the kernel git tree on kernel.ubuntu.com
[10:12] <mne> thanks
[10:13] <apw> mne what do you mean by 'the memory segments the kernel is using' ?
[10:13] <apw> the kernel generally uses all memory for something
[10:14] <apw> you can see the memory segments for each process in /proc/<pid>/maps, but that isn't the kernels use
[10:14] <mne> well, I'm just playing a bit with kernel runtime patching. And as soon as I write to a valid address, the kernel crashes. I just write one single byte and the byte value is the same than the value that's already on that memory position
[10:15] <apw> crashes with what error?
[10:15] <mne> With the vanilla kernel it works
[10:16] <apw> from what context are you trying to write, what sort of place are you trying to write
[10:17] <mne> it's in entry_32. I'm trying to patch an instruction byte. I'm just rebooting the image so that I can give you the exact error message
[10:17] <amitk> mne: what interface are you using? /dev/kmem ?
[10:18] <mne> My code is inside a kernel module. I'm getting the address through an exported kernel symbol
[10:18] <apw> its entirly possible those code pages are r/o in the MMU, as there is no good reason for them to be writable
[10:19] <mne> is that a difference between the ubuntu and the vanilla kernel ?
[10:19] <apw> by preventing them being writable a vector for attack is made more difficult
[10:20] <apw> i am supprised its not the same in vanilla, but it could be app armour
[10:20] <apw> anyhow, let us know the actual error
[10:20] <mne>  BUG: unable to handle kernel paging request at c0104010
[10:20] <mne> I'm pasting the whole message on pastebin
[10:20] <mne> if you want
[10:20] <apw> yep
[10:21] <mne> I'm playing with an old kernel rootkit for security research (I want to know how it works)
[10:22] <mne> http://pastebin.com/m1138ecfb
[10:26] <apw> i assume that that is the write, so it does look like you have written somewhere early in the kernel image and been told NO
[10:26] <mne> so the address is just not writeable ?
[10:27] <mne> The address itself is correct, i have verified that
[10:28] <apw> you have cirtainly hit a protection fault
[10:28] <apw> and if you are writing to the right place, and the address is believeable for the kernel code
[10:29] <apw> then it looks to be protected, which would be my expectation actually
[10:29] <mne> hmm, ok. thanks for helping
[10:29] <mne> Where would I have to look to see which memory regions are protected ?
[10:30] <mne> you said it's inside mmu ?
[10:30] <apw> i would guess app armor has changed the way the kernel protects itself if vanilla is not
[10:30] <apw> the page tables hold the protection information for everything including the kernel
[10:30] <mne> good, I'll have a look there then. thanks
[10:31] <mne> I have to leave for work now, I'll look at it afterwards
[12:15] <tim> hi ... got a slightly off-topic question ... is there an ubuntu package providing the man pages for the kernel routines?
[12:42] <apw> tim manpages-dev perhaps?
[12:45] <tim> apw, unfortunately not ... the only manpages for kernel routines i found, are part of `freebsd-manpages', describing freebsd kernel functions :/
[12:46] <apw> which manpage are you after
[12:47] <tim> kfree ... i found a man page on the net, but would prefer to be able to read them offline
[12:48] <cking> as far as I know there are no kernel API man pages available
[12:50]  * amitk nods
[12:51] <tim> ah, that would explain, why i don't find them ... thanks ...
[12:51] <amitk> the Documentation directory, Linux Device Drivers, and such books are your best bed
[12:51] <amitk> *bet
[12:56]  * apw agrees
[13:03] <cking> or the kernel source :-)
[14:52] <feroz> hello!
[14:53] <GCF> hello feroz (anti vent :p)
[14:53] <feroz> :D
[14:53] <feroz> Anyone is familiar with hid devices here?
[15:04] <fabbione> smb_tp: please pull from here http://kernel.ubuntu.com/git?p=fabbione/ubuntu-hardy.git;a=summary
[15:05] <fabbione> smb_tp: the only thing is that i was not able to verify if there was an ABI change. It will probably tell you that there is a module or two more
[15:05] <fabbione> smb_tp: let me know if you need anything else
[15:05] <smb_tp> fabbione, ok. That should be ok. More symbols are accepted. Just changes would be bad
[15:07] <fabbione> smb_tp: yeah i know the story... but i don't know if you made your checks stricter than when I first wrote them :)
[15:07] <fabbione> anyway.. only one change in that tree
[15:07] <fabbione> it's on your latest hardy tree as of 10 minutes ago checkout
[15:08] <smb_tp> fabbione, no not stricter. :) Just Ben got annoyed enough with the diff type approach that he changed it to an enhanced perl compare.
[15:09] <fabbione> i can't say on public IRC what's passing through my mind :)
[15:09] <fabbione> Ben is a ***** developer :P
[15:09] <fabbione> just because I have been friend with ben for way too long ;)
[15:10] <smb_tp> heh. :) Guess I have to ask him next week :)
[15:10] <fabbione> ahah sure
[15:10] <fabbione> i am off
[15:10] <fabbione> have fun
[15:10] <smb_tp> thanks, u2
[16:21] <mne_> Hi, how can I change a kernel page protection entry ? there is change_protection, but the symbol is not exported
[16:44] <apw> they are probabally hinting that should shouldn't be doing that
[21:43] <sconklin> is there anything I should know before I dive into several quickcam driver bugs? 
[21:44] <cking> sconklin: I suspect you will find out
[21:46] <sconklin> haha. yeah.
[21:48] <sconklin> there are some comments in some bugs that make me think maybe we're already carrying some patches that aren't upstream, that's the first thing I'll go investigate
[21:51] <cking> sconklin: what's the probs with the quickcam driver?  The issues I've seen are usually weird frame offset / geometry problems which need tweaking for different variants of the hardware
[21:55] <sconklin> there are various problems, differing slightly with model number. One "doesn't work" when plugged in, but some workarounds get it to work with funky video. Another doesn't have hal detect it as v4l capable.
[21:55] <sconklin> The bug numbers I'm looking at are:
[21:56] <sconklin> bug 196811 bug 22070 bug 134285
[22:01] <cking> the slightly different model number can be subtle - sometimes the chipset is completely different - the pressure for cost reduction means that chipsets can radically change between model numbers
[22:02] <sconklin> yeah, I was aware of that, thanks. I've dealt with wireless adapters that are packaged identically but have different chipsets and identifiers.
[22:03] <cking> ..yeah - these kind of fun issues just to keep us on our toes!
[22:03]  * cking wonders if he can fit one more build in before the day is done
[22:09]  * sconklin knows he can't
[22:13] <cking> depends on how long one's day is really :-)
[22:15] <sconklin> tonight we have a band parents supper, so no working late for me
[22:17] <cking> good plan.
[22:17]  * cking bailing out - build done, test failed, respin another day