| joshhunt | sconklin: around? | 00:17 |
|---|---|---|
| === BruceMa is now known as BruceMa_afk | ||
| === hughhalf is now known as hugh_afk | ||
| === smb` is now known as smb | ||
| === hugh_afk is now known as hughhalf | ||
| psino | I've tried building an ubuntu kernel with a local version string (both by configuring the local version in the kernel menu config (general -> local version) and by using dch, but both methods give me the following error: https://gist.github.com/nkvoll/46509fa1aaaeda5441ef | 09:03 |
| psino | i've tried searching for a solution, but I've been unable to find a way to build a kernel with a custom name so that I can distinguish it from the default, official one | 09:04 |
| psino | I've successfully built a kernel without modifying the name in any way (following https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel), but it makes my custom kernel a bit hard to differentiate from the official ones | 09:06 |
| apw | psino, so you changed the flavour name ? | 09:12 |
| apw | 3.8.0-17-generic-mmu | 09:12 |
| apw | and i would guess you didn't change the list of flavours? | 09:12 |
| smb | psino, You probably just want to modify the version number in the debian.master/changelog | 09:12 |
| psino | first I tried only changing the local version during editconfigs, it failed, then I used "dch --local -mmu-patched" (which seems to ignore the -patched-part) | 09:13 |
| apw | psino, what is the version number as shown in the top of debian.master/changelog | 09:13 |
| psino | linux (3.8.0-17.27) raring; urgency=low | 09:14 |
| apw | dch doesn't really work with the kernel, cause debian/changelog is not the master | 09:14 |
| smb | So change that into 3.8.0-17.27+mmupatched | 09:14 |
| apw | psino, using a - in that string is destined for failure | 09:14 |
| psino | ok, do I need to do anything else other than change the first line in the changelog? | 09:15 |
| apw | psino, to get a unique version, only to clean ... debian/rules clean | 09:16 |
| smb | as long as the change itself would not change the abi, but you will notice that | 09:17 |
| psino | it probably doesn't, since I managed to build a working kernel (booted on two different instances) when I didn't change the version string | 09:19 |
| ppisati | lp 1168039 | 09:20 |
| ubot2 | Launchpad bug 1168039 in linux (Ubuntu) "highbank: network corruption" [High,Confirmed] https://launchpad.net/bugs/1168039 | 09:20 |
| apw | ppisati, i suspect you will have to build him some kernels with highbank config for that bisect to work | 09:26 |
| ppisati | apw: yeah, already doing that :) | 09:26 |
| ppisati | apw: we miss you in mumble | 09:27 |
| smb | maybe he will be back on Monday ... maybe not | 09:27 |
| ppisati | :( | 09:33 |
| ppisati | apw: do you think it would be possible to have mainline compiled for armhf from now on? | 09:41 |
| apw | ppisati, it does already in fact, but ... remember only ones built in raring and in raring since you added highbank to the configs would be a highbank compatible | 09:42 |
| apw | ppisati, mostly we are building it for 'does it build' testing than for anything else | 09:42 |
| ppisati | apw: yeah, from now on i mean | 09:43 |
| ppisati | apw: we could build mainline for armhf using 'multi_v7_defconfig' | 09:44 |
| ppisati | apw: or do we use our conig actually? /me never checked... | 09:44 |
| apw | ppisati, we use 'our' config modulo any changes since then where we take the default answers | 10:04 |
| apw | dk | 12:29 |
| apw | k | 12:29 |
| apw | bah | 12:30 |
| rtg_ | apw, how the N7 USB config stuff going ? | 12:54 |
| rtg_ | how is* | 12:54 |
| apw | rtg_, going ok in one sense, i am struggling with some other changes i have made which have made the damn kernel tooo big | 13:02 |
| apw | rtg_, did you see: 14:02:33 apw | rtg_, going ok in one sense, i am struggling with some other changes i have made which have made the damn kernel tooo big | 13:13 |
| rtg_ | apw, nah, missed that. busy updating kernels etc | 13:14 |
| apw | rtg_, enabling the filesystms we want triggers the initramfs to bloat needlessly and it won't fix, anyhow working on it | 13:15 |
| rtg_ | apw, given that the N7 isn't _really_ a general purpose platform, can we disable some of the cruft ? | 13:16 |
| rtg_ | apw, ppisati says the N4 is working for him, so I'm gonna get it in the archive. | 13:17 |
| apw | rtg_, well the issue is that things which are modules get pulled in to initramfs, we need some way to say not to do that, i think we can say "just this list" and put nothing in it. for now i have dropped out the fliesystems changes and moved on, and will come back to it | 13:17 |
| apw | rtg_, great, now i have a 'proceedure' for this i can do the same to n4 | 13:17 |
| rtg_ | apw, cool | 13:17 |
| ppisati | rtg_: yep, n4 works here | 13:21 |
| * ppisati is stuck with calxeda bugs else he would tackle the n[4|7] happily :( | 13:21 | |
| ppisati | ftrace is broken on n4 | 13:21 |
| rtg_ | ppisati, did you update the wiki on how to install the new kerenl ? | 13:22 |
| ppisati | the n7 has the touchscrenn patch problem | 13:22 |
| ppisati | rtg_: i used that procedure | 13:22 |
| ppisati | rtg_: i installed the .deb package | 13:22 |
| ppisati | rtg_: then | 13:22 |
| ppisati | rtg_: aboot -u /dev/block/mmcblk0p6 -k /boot/vmlinuz-foobar | 13:22 |
| ppisati | *abootimg | 13:22 |
| rtg_ | I wonder if we could get ogra_ to update flash-kernel | 13:22 |
| ogra_ | for what exactly ? | 13:24 |
| rtg_ | ogra_, for the n4 | 13:24 |
| ogra_ | get me the data :) | 13:24 |
| ogra_ | shouldnt be any prob to add it to all.db | 13:24 |
| rtg_ | ogra_, how about if I send you a patch ? I've got an N4 to experiment with. | 13:25 |
| ogra_ | yeah | 13:25 |
| ogra_ | you should be able to just copy the db entry of grouper and minimally modify it | 13:26 |
| rtg_ | ogra_, ack | 13:26 |
| === rsalveti is now known as Rsalveti_ | ||
| === Rsalveti_ is now known as rsalveti | ||
| === hggdh_ is now known as hggdh | ||
| bullgard4 | Where is the function of the kernel process [netns] described? | 15:32 |
| joshhunt | sconklin: i'm seeing differences b/t the diff you prepared and what's posted on the usn page. | 15:44 |
| sconklin | the one I prepared, or the one rtg did? | 15:44 |
| pmatulis | is this wiki [1] official and accurate? | 15:44 |
| pmatulis | [1]: https://wiki.ubuntu.com/Kernel/LTSEnablementStack | 15:44 |
| sconklin | joshhunt: ^^ | 15:45 |
| joshhunt | sconklin: good question, let me see which one i grabbed. | 15:45 |
| joshhunt | sconklin: it's the one rtg provided the link for | 15:45 |
| joshhunt | sconklin: i thought they were the same file | 15:45 |
| joshhunt | sconklin: let me grab the one from your link and check | 15:46 |
| sconklin | no, I linked to the wrong one. I'll take a look | 15:46 |
| sconklin | no, Mine is from the wrong release, the latest one | 15:46 |
| sconklin | joshhunt: ^^ | 15:46 |
| joshhunt | sconklin: ok, thx. one diff i see is this: linux-3.2/arch/arm/mach-omap2/include/mach/omap4-common.h | 15:46 |
| sconklin | let me prepare one for the correct release and compare it with the one rtg did | 15:47 |
| sconklin | it'll take me a bit | 15:47 |
| joshhunt | sconklin: that file exists in your patch, but not the kernel linked on the usn page | 15:47 |
| joshhunt | sconklin: sure, np | 15:47 |
| joshhunt | sconklin: let me know if you want a list of the diffs, if that will help pinpoint what went wrong, although it'd be good to verify the one on the usn page is correct also. | 15:48 |
| sconklin | joshhunt: ack, thanks | 15:49 |
| smb | pmatulis, Looks to me like the correct one / official one | 15:50 |
| pmatulis | smb: thanks. why does it mention only x86? | 16:01 |
| smb | ogasawara, ^ | 16:02 |
| ogasawara | pmatulis: because we only provide HWE kernels for x86 | 16:04 |
| ogasawara | pmatulis: we don't provide backport HWE kernels for say our arm flavors | 16:04 |
| pmatulis | ogasawara: ok, i was confused thinking x86 does not include amd64 | 16:05 |
| sconklin | joshhunt: can you point me to the exact usn page you're talking about? I want to make sure we're on the same page | 16:09 |
| joshhunt | sconklin: sure, https://launchpad.net/ubuntu/+source/linux/3.2.0-40.64 | 16:10 |
| sconklin | Thanks, now I'm sure I have the right tag | 16:11 |
| smb | henrix, Hey just wanted to let you know that I have been running the master-next lucid in a xen pv and hvm guest. Ok, the hvm guest still has an eta of 80mins on the regression tests but in general I think we can say those xen ds patch looks good | 16:32 |
| henrix | smb: cool, thanks. i guess that if there was a prob with that backport it would crash ugly during boot :) | 16:33 |
| smb | henrix, one would guess. Though it did not crash ugly on boot before either. :) | 16:34 |
| henrix | smb: heh true :) | 16:34 |
| henrix | thanks for testing that | 16:34 |
| smb | no prob | 16:35 |
| sconklin | joshhunt: ok, there was some confusion here. There are diffs that get generated as part of the packaging, which are diffs from the original tarball for for the series. We an reproduce these. | 16:44 |
| sconklin | But the diffs on the page you linked are generated by launchpad as a consequence of the order in which packages are uploaded and copied to -proposed, and we cannot reproduce those | 16:44 |
| sconklin | we'll try not to let this happen again | 16:46 |
| joshhunt | sconklin: i'm not sure what you mean exactly. do you know why the diff rtg provided did not match what's on launchpad? | 16:46 |
| ppisati | ok, friday evening here | 16:48 |
| ppisati | gym -> booze -> EOW | 16:48 |
| sconklin | joshhunt: show me precisely which diff you mean by "what's on launchpad" | 16:48 |
| joshhunt | sconklin: if i take the diff rtg linked to and apply it to a vanilla kernel and then download https://launchpad.net/ubuntu/+archive/primary/+files/linux_3.2.0-40.64.tar.gz the contents do not match when I diff -Naur them | 16:49 |
| sconklin | joshhunt: define "vanilla kernel" - do you mean the .orig tarball we use to package with? Because that's what those diffs are generated against | 16:51 |
| joshhunt | sconklin: so the only reason this concerns me is it raises a question to me as to which one is "correct" | 16:51 |
| joshhunt | sconklin: kernel.org tarball | 16:51 |
| joshhunt | sconklin: i make an assumption that is the same as your .orig tarball | 16:51 |
| joshhunt | sconklin: if you tell me what's on the launchpad page is correct, then i will just generate my own diff b/t 3.2.0 from kernel.org and linux_3.2.0-40.64.tar.gz and use that for this releaes | 16:52 |
| sconklin | joshhunt: ok, now I get what you're asking, let me check on some things. | 16:54 |
| sconklin | joshhunt: 1. Yes, our .orig is the same as upstream | 17:04 |
| sconklin | 2. try the diff here and see if it looks better: http://people.canonical.com/~sconklin/ | 17:04 |
| joshhunt | sconklin: so it seems it's the same as the one rtg gave me yesterday | 17:08 |
| joshhunt | sconklin: you can verify for yourself by downloading the file from https://launchpad.net/ubuntu/+archive/primary/+files/linux_3.2.0-40.64.tar.gz and diff'ing that with your patch + orig tarball | 17:09 |
| sconklin | doing that | 17:09 |
| joshhunt | sconklin: but i see things like linux-3.2/arch/arm/mach-omap2/include/mach/omap4-common.h is in your diff, but not in the 40.64 tarball | 17:09 |
| joshhunt | sconklin: hmm actually i think i worded that last statement incorrectly | 17:12 |
| apw | sconklin, when you make an orig + patch version you will have files which would have been 'deleted' still present in the combination ... because the +diff cannot represent the removal | 17:18 |
| apw | sconklin, so if that differs from one where you missed the orig, that is not unexpected. you should compare to one before which has an orig | 17:18 |
| sconklin | apw: maybe that accounts for it | 17:18 |
| sconklin | thanks | 17:18 |
| joshhunt | apw: just curious, why can't the diff represent the removal? | 17:22 |
| joshhunt | sconklin: to correct my prev statement, arch/arm/mach-omap2/include/mach/omap4-common.h is actually not in the linux_3.2.0-40.64.tar.gz tarball. | 17:30 |
| joshhunt | sconklin: apw seems to be onto something, when i go through the diff i believe the differences are only whole files which are not present in the linux_3.2.0-40.64.tar.gz | 17:30 |
| kamal | joshhunt: I just came to the exact same conclusion -- its all just the deleted files which aren't represented in the diff | 17:31 |
| sconklin | josh, our testing here (Kamal looked at this also) indicates that this is the case. All differences are attributable to deleted files | 17:31 |
| sconklin | thanks, apw | 17:32 |
| kamal | specifically, that list of deleted files (not counting a bunch of .gitignore files) is http://paste.ubuntu.com/5702168/ | 17:33 |
| joshhunt | kamal: yes that's the same list i get thanks. | 17:34 |
| kamal | joshhunt: and just fyi, along the way I also verified that (a) our .orig tarball is identical to the upstream 3.2 tarball, and (b) the sconklin/rtg diff's are precisely what would have been produced, if that 40.64 package had been constructed with the .orig. | 17:36 |
| joshhunt | kamal: ok thanks. i appreciate all (sconklink, apw, kamal) of your help | 17:36 |
| sconklin | and in the process, uncovered an interesting side effect of our build process that resulted in my diff being different than rtg's | 17:37 |
| joshhunt | are these deleted files usually present in diff you normally post for USNs? | 17:38 |
| joshhunt | and i just didn't notice them | 17:38 |
| rtg_ | ogasawara, you can update a blueprint, I got the N4 kernel uploaded this AM. working on getting flash-kernel functional. | 17:39 |
| ogasawara | rtg_: nice! | 17:39 |
| rtg_ | ogasawara, OMG! tl;dr - 'UBUNTU: SAUCE: cpuidle: Fix NULL pointer dereference when off-lining CPU's' :) | 17:41 |
| ogasawara | rtg_: way too long, just ack it | 17:42 |
| rtg_ | ogasawara, done | 17:42 |
| * rtg_ -> lunch | 17:42 | |
| * henrix -> EOD | 17:46 | |
| joshhunt | sconklin: i'm just trying to make sure i understand what happened. how are you generating the diff you provided to me? git-diff? | 17:50 |
| sconklin | joshhunt: I rewound the git repo to the tag we released from, then generated a source package with a diff against the .orig tarball (the way we normally package) | 17:51 |
| sconklin | so it was generated by producing a source package just like a release. | 17:51 |
| sconklin | joshhunt: I can give you instructions for how to do the same thing | 17:51 |
| sconklin | if you want to verify it that far | 17:51 |
| joshhunt | sconklin: that would be cool, as i'm trying to convert us over to pulling this stuff from git anyway. i'd be interested in your process. | 17:52 |
| sconklin | joshhunt: you know how to clone our repo already? | 17:52 |
| joshhunt | sconklin: yep | 17:53 |
| sconklin | so basically, find the rigth tag and reset to that. In this case it was: git reset --hard 985689a | 17:54 |
| sconklin | then follow the directions here: | 17:54 |
| sconklin | https://wiki.ubuntu.com/KernelTeam/StableHandbook/StablePackageBuilding | 17:54 |
| sconklin | which in this case was: | 17:54 |
| sconklin | git clean -dxf | 17:54 |
| sconklin | fakeroot debian/rules clean | 17:55 |
| sconklin | debuild -S -I -i -uc -us -sa -v3.2.0-39.62 | 17:55 |
| sconklin | and if you have the .orig tarball in the directory above the repo, it should all work | 17:55 |
| kamal | sconklin, joshhunt: fyi, instead of the initial "git reset", it also works to just do: git checkout Ubuntu-3.2.0-40-64 | 17:55 |
| joshhunt | sconklin: thanks so much, i appreciate it. | 17:56 |
| joshhunt | kamal: thanks | 17:56 |
| kamal | note also that the "-v" flag there is not relevant -- you'll get the same diff.tar.gz with or without it | 17:56 |
| kamal | joshhunt: note also that the orig tarball in .. must be named "linux_3.2.0.orig.tar.gz" ... the debuild process won't find it if you leave named as kernel.org provides it. | 17:57 |
| joshhunt | kamal: ok thakns | 17:58 |
| joshhunt | will this process generate a package or a diff? | 17:58 |
| sconklin | both | 17:58 |
| joshhunt | awesome | 17:59 |
| kamal | joshhunt: it will generate a "source package", which is comprised of a few files including the .diff.tar.gz | 17:59 |
| joshhunt | ok so then if in this particular case if i were to apply the diff generated here to an orig tarball and diff that against the package which is created, we'd see the same thing with the deleted files not being in the diff. is that correct? | 17:59 |
| joshhunt | if so then i think i finally understand :) | 18:00 |
| kamal | joshhunt: yes, that's exactly the procedure I did | 18:00 |
| joshhunt | kamal: awesome thanks so much for your help. i will leave you all alone now :D | 18:00 |
| joshhunt | sconklin: thanks again | 18:01 |
| kamal | joshhunt: no worries -- its helping us refine our process too, and that's a good thing | 18:01 |
| sconklin | joshhunt: np. | 18:03 |
| ogasawara | rtg_: I assume I can ping rsalveti to try rolling the N4 kernel into the phablet image? or would you prefer I wait till we sort the flash-kernel bits | 18:11 |
| rtg_ | ogasawara, yeah, wait until I'm sure flash-kernel is correct. likely someimte next week when I sync up with ogra_. | 18:11 |
| ogasawara | rtg_: ack | 18:11 |
| ogra_ | well, we dont have the n7 kernel in use on the touch images either, rsalveti can surely start playing woth it and test etc | 18:13 |
| ogra_ | flash-kernel will need adjustment for both | 18:14 |
| rtg_ | ogra_, Paolo has to figure out the touch pad issue first. | 18:14 |
| ogra_ | ah, right, there was that | 18:14 |
| rsalveti | ogasawara: flash kernel will only be useful when we finish the container work anyway, so we can at least use the same git tree | 18:14 |
| rsalveti | while we make the package available and tune flash-kernel for later | 18:14 |
| rsalveti | ogra_: waiting paolo ack on that as I don't have the hardware | 18:15 |
| ogra_ | rsalveti, why would the container have anything to do with it ? | 18:15 |
| rsalveti | I only got galaxy nexus, nexus 4 and 10 | 18:15 |
| rtg_ | rsalveti, I think I have it working on the N4 within the Ubuntu chroot. | 18:15 |
| rsalveti | ogra_: because then the entire kernel and boot image is maintained by the ubuntu side | 18:15 |
| ogra_ | as long as we dont overwrite the initrd ... | 18:15 |
| rsalveti | sure, we'd need some temporary hack to reuse whatever it's available at the bootimg | 18:15 |
| ogra_ | right, but even in todays model we could updatte vmlinuz | 18:15 |
| rsalveti | which doesn't make sense | 18:15 |
| rsalveti | otherwise we'll replace the bootimg and the device will not boot | 18:16 |
| ogra_ | thats what i mean. you dont replace bootimg | 18:16 |
| rsalveti | if we get ubuntu as the main host, it'll all just work once we finish the flash-kernel piece | 18:16 |
| ogra_ | only vmlinuz | 18:16 |
| rsalveti | right, which will not affect the device | 18:17 |
| ogra_ | on /dev/block/mmcfoo ... | 18:17 |
| rsalveti | both kernel and initrd is part of the boot.img | 18:17 |
| ogra_ | i know | 18:17 |
| rsalveti | there's no single partition for the kernel | 18:17 |
| ogra_ | but initrd in android doesnt carry anything kernel relevant | 18:17 |
| ogra_ | there is the bootimg partition | 18:18 |
| rsalveti | right | 18:18 |
| ogra_ | which abootimg can directly operate on | 18:18 |
| rsalveti | we could extract, change and update, I'm just saying we don't need to do that now | 18:18 |
| rsalveti | as we'll change it soon anyway | 18:18 |
| ogra_ | why ? | 18:18 |
| rsalveti | once we start using our own initrd | 18:18 |
| ogra_ | abootimg -u /dev/block/mmcfoo -k /boot/vmlinuz-xyz | 18:18 |
| ogra_ | that works today | 18:19 |
| ogra_ | no need to extract | 18:19 |
| rsalveti | cool, that makes it easier | 18:19 |
| ogra_ | right | 18:19 |
| ogra_ | if we cant switch the container we can use that method | 18:19 |
| rsalveti | sure | 18:19 |
| ogra_ | (and probably without even involving f-k) | 18:20 |
| rsalveti | wouldn't it be better to just use f-k and make f-k call abootimg? | 18:20 |
| ogra_ | well ... abootimg has all checks we need ... and the kernel package knows which device we want to flash to | 18:20 |
| rsalveti | ogra_: right | 18:21 |
| ogra_ | i would just have the kernel package ship the proper postinsts | 18:21 |
| rsalveti | ogra_: how this is done with nexus 7 for desktop? | 18:21 |
| ogra_ | and hooks for initrd .... | 18:21 |
| ogra_ | f-k using the ac100 method | 18:21 |
| rsalveti | right | 18:21 |
| ogra_ | we can indeed use that | 18:21 |
| ogra_ | but i find it less complex to have the kernel just ship the right thing in case we dont touch the initrd | 18:22 |
| ogra_ | if we flip the containers f-k might be better thanks to its initrd hooks and triggers | 18:22 |
| rtg_ | ogra_, rsalveti: so I should just quit messing with f-k and just build it into the kernel postinst ? | 18:22 |
| ogra_ | not yet ... we need to know what container model we will use | 18:23 |
| ogra_ | i woudl prefer the direct methid if the images stay as is | 18:23 |
| ogra_ | but f-k in case we can move android into its own container | 18:23 |
| ogra_ | (since then we want initrd handling) | 18:23 |
| rsalveti | right | 18:23 |
| rsalveti | then we might know better next week | 18:24 |
| rtg_ | ogra_, well, I've gota functional Quantal version of f-k | 18:24 |
| rsalveti | once mike finalizes his investigation | 18:24 |
| ogra_ | hopefully | 18:24 |
| ogra_ | time is getting short for uploads | 18:24 |
| rsalveti | yeah | 18:24 |
| ogra_ | i thinnk lfinal freeze is next thu (didnt check the schedule but it should be around next week) | 18:24 |
| rsalveti | well, we don't necessary need to worry with raring anyway | 18:25 |
| ogra_ | and if we change f-k's android method that needs testting on ac100 and n7 desktop for verification | 18:25 |
| rsalveti | right | 18:25 |
| ogra_ | true | 18:25 |
| rsalveti | you'll be testing that for us anyway :P | 18:25 |
| ogra_ | haha | 18:26 |
| rsalveti | don't have n7 neither ac100 | 18:26 |
| ogra_ | expectations :) | 18:26 |
| ogra_ | i dont even know if the archive kernel still works on the n7 | 18:26 |
| ogra_ | i guess i should test on the weekend :) | 18:26 |
| rsalveti | :-) | 18:26 |
| ogra_ | i fear paolo uses the android config | 18:27 |
| ogra_ | (though i think he said he tested it) | 18:27 |
| rsalveti | brb | 18:27 |
| janimo | rtg_, hi is there a more or less comprehensive list of ubuntu kernel security CVEs so far in a single place | 19:10 |
| rtg_ | janimo, you'd have to ask my security dude sconklin | 19:11 |
| janimo | ubuntu-security-announce ml is what I see closest, but it is not kernel only | 19:11 |
| janimo | rtg_, sconklin I am interested in aproximately how many of the security issues are arch or driver dependent vs those that affect any kernel | 19:13 |
| janimo | to have an idea how vulnerable a random android or BSP based kernel for a single ARM SoC would be on average, knowing the kernel security fixes cover a much wider surface area than a single specialized kernel has built in | 19:14 |
| rtg_ | janimo, I guess you could grep commit logs looking for CVE. | 19:14 |
| janimo | rtg_, yeah, that's why I asked for a preexisting list or even such a rough classification which may have already been done :) | 19:16 |
| rtg_ | janimo, I am not aware of any such classification. | 19:17 |
| janimo | or a guesstimate of someone doing this on a daily basis who | 19:17 |
| bjf | janimo, you can also look at the changelog. cves are indicated | 19:17 |
| janimo | s/who// | 19:17 |
| janimo | bjf, right, I am aware of those too, but thanks :) . As you can see I am lazy and first look for anything that may be done already | 19:18 |
| bjf | janimo, there is also http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html | 19:18 |
| bjf | janimo, but that doesn't cover ones that have been closed out | 19:18 |
| janimo | bjf, I guess the UBuntu kernel CVE is more or less the same as upstream kernels right? | 19:18 |
| janimo | CVE list that is | 19:19 |
| bjf | janimo, i'd expect them to be very close if not the same | 19:19 |
| janimo | hm, than this may be a good list | 19:20 |
| janimo | http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/cvssscoremin-7/cvssscoremax-7.99/Linux-Linux-Kernel.html | 19:20 |
| janimo | or something on that website anyway | 19:20 |
| bjf | jjohansen, may know of something | 19:20 |
| janimo | or this may be a cleaner list http://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33 | 19:22 |
| jjohansen | hrmm, I have really dived into that kind of data yet, it would be a good idea to shift through the CVEs we have had in the past and see what it shows | 19:22 |
| * janimo is relieved to see there have been 0 CSRF vulnerabilities in the Linux kernel | 19:22 | |
| jjohansen | and yes our kernel CVEs are the same as upstream | 19:23 |
| janimo | jjohansen, the cvedetails page seems really nice, but I do not see classification based on modules or other components. That may indeed need some extra greeping work, hopefully CVEs have the affected source file paths in a searchable location | 19:25 |
| jjohansen | janimo: right I am not aware of anything breaking it down by module/driver/subsystem it would be interesting to see | 19:26 |
| janimo | no idea if there's a CVE database in a machine-friendly format | 19:26 |
| jjohansen | ours isn't bad we process it with scripts, it does have some issues | 19:27 |
| janimo | a more or less fixed form is good too, right | 19:28 |
| jjohansen | sure | 19:28 |
| jjohansen | I'm wondering how far bug our break-fix entries (git commits that caused the cve and ones that fixed it) go, I think its only a couple of years | 19:30 |
| janimo | jjohansen, based on what you saw so far and with no such analysis being done, what would you estimate is the split between vulnerabilites that would affect almost every kernel and those that involve rarely used drivers or more obscure FSs or network fucntionality? | 19:30 |
| janimo | jjohansen, I do not need too much history, just an idea of how much chance a given CVE has of affecting an ARM kernel built for a single SoC supporting only the drivers that areneeded on a single mobiel device | 19:31 |
| janimo | so likely no advanced network or server storage stuff, no huge x86 or supercomputer data buses, etc | 19:32 |
| jjohansen | hrmmm hard to say I would guess it tips to the obscure fs or network functionality, but I'm not sure how much 60/40, 70/30 ? | 19:32 |
| janimo | just a random Android kernel from a mobile phone | 19:32 |
| janimo | from the few android kernels I saw, their updates seem to cover hw enablement issues and not really securitty updates | 19:32 |
| janimo | probably becasue user-space also has less chances of doing dangerous stuff | 19:33 |
| * ogasawara lunch | 19:39 | |
| * rtg_ -> EOW | 19:59 | |
| === mehdi is now known as mmsabwat | ||
| === hggdh_ is now known as hggdh | ||
| yigal | To use an old device with 12.10 I need to patch its kernel. Where can I find an up-to-date accounting on how the Ubuntu kernel should be patched and then (re)built? Secondly, I need instructions specifically on compiling its kernel on another platform, as my desktop is much faster. | 23:04 |
| yigal | I believe I need to for EZEX touchscreen | 23:04 |
| yigal | unless someone else knows evtouch or other will work with tweaks? | 23:05 |
| bjf | yigal, https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel | 23:07 |
| yigal | lol | 23:08 |
| yigal | and then he's out | 23:08 |
| yigal | It's just been a couple years since compiling and new tools seem to come more frequently than that so | 23:12 |
| yigal | So I've tried through the source in a i386 chroot environment to compile but have had issues. Owell it's always fun to do this type of stuff. | 23:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!