| sconklin | lamont: I just posted some test kernels for the NAT/filtering issue, there's a link in the bug. If you have a chance to test those, I'll probably follow with further test kernels, Thanks! | 02:09 |
|---|---|---|
| lamont | ok | 02:38 |
| lamont | sconklin: ^^ | 02:38 |
| sconklin | ack | 02:40 |
| === smoser` is now known as smoser | ||
| === _LibertyZero is now known as LibertyZero | ||
| * apw yawns | 08:35 | |
| RAOF | More bees! | 08:35 |
| jk- | BEES! | 08:35 |
| apw | COVERED in bees | 08:36 |
| ppisati | apw: are you working today? | 11:33 |
| apw | ppisati, yep and here, was that you i heard? | 11:33 |
| ppisati | apw: so, i have a cve fix that imo is not needed in a branch | 11:34 |
| ppisati | apw: how does it work? shall someone review it? | 11:34 |
| ppisati | apw: it's not event in the .y tree | 11:34 |
| apw | ppisati, if you believe its not needed, then we do nothing and move on | 11:35 |
| ppisati | ok | 11:35 |
| apw | for example if the code does not exist which is affected, then we just need to mark the CVE task for that release Invalid | 11:35 |
| apw | and let me know so i can make sure the tracker gets updated | 11:35 |
| ppisati | actually the code exist, but it's slightly different | 11:36 |
| ppisati | and it seems the check is already there | 11:36 |
| apw | then thats fine, we trust the triager (you) to work that out | 11:36 |
| ppisati | ok | 11:36 |
| ppisati | https://bugs.launchpad.net/ubuntu/lucid/+source/linux-fsl-imx51/+bug/737024 | 11:46 |
| ubot2 | Ubuntu bug 737024 in linux-mvl-dove "CVE-2010-4263" [Undecided,In progress] | 11:46 |
| ppisati | this one is not needed in fsl-imx51 | 11:46 |
| ppisati | and launchpad just ate my comment | 11:46 |
| ppisati | ... | 11:46 |
| ppisati | ok, done | 11:47 |
| ppisati | move it to "Not needed" in the tracker | 11:47 |
| apw | ppisati, will do | 11:47 |
| ppisati | something strange with one cve fix | 12:13 |
| ppisati | it's there, so it's not a security problem | 12:13 |
| ppisati | but the commit message was inverted between 2 patches | 12:13 |
| ppisati | and then one of them was applied again | 12:13 |
| apw | ppisati, so we applied it, reverted it and reapplied it ? | 12:17 |
| ppisati | apw: nope | 12:17 |
| ppisati | wait | 12:17 |
| ppisati | CVE-2011-1016 | 12:17 |
| ubot2 | ppisati: The Radeon GPU drivers in the Linux kernel before 2.6.38-rc5 do not properly validate data related to the AA resolve registers, which allows local users to write to arbitrary memory locations associated with (1) Video RAM (aka VRAM) or (2) the Graphics Translation Table (GTT) via crafted values. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1016) | 12:18 |
| ppisati | http://people.canonical.com/~ubuntu-security/cve/2011/CVE-2011-1016.html | 12:18 |
| ubot2 | ppisati: The Radeon GPU drivers in the Linux kernel before 2.6.38-rc5 do not properly validate data related to the AA resolve registers, which allows local users to write to arbitrary memory locations associated with (1) Video RAM (aka VRAM) or (2) the Graphics Translation Table (GTT) via crafted values. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1016) | 12:18 |
| ppisati | and the twp patches: | 12:18 |
| ppisati | http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fff1ce4dc6113b6fdc4e3a815ca5fd229408f8ef | 12:18 |
| ppisati | http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=45e4039c3aea597ede44a264cea322908cdedfe9 | 12:18 |
| ppisati | now, on lucid: | 12:18 |
| ppisati | c0cd753 drm/radeon: fix regression with AA resolve checking | 12:18 |
| ppisati | 7548efe drm/radeon/kms: check AA resolve registers on r300 | 12:18 |
| ppisati | 168a4d2 drm/radeon: fix regression with AA resolve checking, CVE-2011-1016 | 12:18 |
| ubot2 | ppisati: The Radeon GPU drivers in the Linux kernel before 2.6.38-rc5 do not properly validate data related to the AA resolve registers, which allows local users to write to arbitrary memory locations associated with (1) Video RAM (aka VRAM) or (2) the Graphics Translation Table (GTT) via crafted values. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1016) | 12:18 |
| ppisati | 90a458e drm/radeon/kms: check AA resolve registers on r300, CVE-2011-1016 | 12:18 |
| ubot2 | ppisati: The Radeon GPU drivers in the Linux kernel before 2.6.38-rc5 do not properly validate data related to the AA resolve registers, which allows local users to write to arbitrary memory locations associated with (1) Video RAM (aka VRAM) or (2) the Graphics Translation Table (GTT) via crafted values. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1016) | 12:18 |
| ppisati | uhm, ok | 12:20 |
| apw | ppisati, well if you are sure the stuff is applied at the end of the pile then we can porbabally ignore it | 12:20 |
| ppisati | got it | 12:20 |
| ppisati | instead of reverting | 12:20 |
| ppisati | they logicallu reverted the patch using the commit msg | 12:20 |
| ppisati | and then reapplied it | 12:20 |
| ppisati | ok | 12:20 |
| apw | ok so they used a stupid name for the revert, thats fine | 12:21 |
| cdbs | I can see kernels on the mainline PPA, but I can't find any -modules-VERSION packages on kernel.ubuntu.com, will new kernels automatically use modules of the older version already installed on Ubuntu? | 12:44 |
| cdbs | For example, I'm downloading the 3.0 kernel, so will it re-use the modules debs from the 2.6.39 kernel? | 12:45 |
| apw | cdbs, there are no separate modules packages, they are included in the kenel images | 12:47 |
| cdbs | :o | 12:47 |
| cdbs | makes sense | 12:47 |
| === Quintasan_ is now known as Quintasan | ||
| pmatulis | i have many TCP sockets in CLOSE_WAIT states ('till DOS). i realize this generally means an application bug but is there some quick 'n dirty way to get rid of these states in the meanwhile? | 14:09 |
| apw | pmatulis, if they are real i think they have to be maintained to maintain the TCP protocol correctly | 14:10 |
| apw | ppisati, hey, this last commit on the ti-omap4 pull request, is that a CVE fix ? | 14:10 |
| apw | (looks to be), if so then it should have CVE-NNNN-MMMM added abouve your signed-off-by | 14:11 |
| apw | also as this one has not been reviewed before it seems, it likely should be send out to the list for review and ack before application | 14:11 |
| pmatulis | apw: i'm sorry, i don't understand you. are you saying 'no' to my question? will adjusting other state values (sysctl) help (specifically WAIT_TIME)? | 14:14 |
| apw | you may get some help reducing those, but i think those waits are needed for proper operation on lossy links | 14:14 |
| apw | so there is no way to remove them en-toto | 14:15 |
| ppisati | apw: it's identical to the same fix in all the others branch | 14:16 |
| apw | ok will check into that and let you know thanks | 14:17 |
| pmatulis | apw: it's not a lossy link (between 2 lan servers) | 14:17 |
| ppisati | apw: anyway, what if axe that from my maverick/ti-omap4 so you can uppload the rest? | 14:17 |
| apw | ppisati, leave it with me, if i decide not to take it i'll take the rest without you needing to do anything, i'll reply in email | 14:18 |
| ppisati | ok | 14:18 |
| apw | once i've reviewed the rest | 14:18 |
| ogasawara | apw: were you able to get around to disabling the cron for O builds yesterday? just want to make sure before I push the bits I have. | 14:23 |
| apw | i just had a look and actually we don't do pre-proposed for O yet, as there are no O PPAs yet | 14:24 |
| apw | ogasawara, ^^ | 14:24 |
| apw | so you are safe | 14:24 |
| ogasawara | apw: cool. I'm just gonna twiddle the changelog in my startnewrelease commit to version 3.0-0.1 and then push | 14:25 |
| apw | ok | 14:25 |
| apw | i'll get the bits to make it work on the top pronto | 14:25 |
| apw | ogasawara, did you do the abi as well ? | 14:34 |
| ogasawara | apw: yep | 14:34 |
| ogasawara | apw: I almost forgot | 14:34 |
| apw | i made that mistake the first time :( | 14:34 |
| ogasawara | apw: should be pushed now | 14:34 |
| apw | ppisati, ok all pushed ... thanks :) | 14:46 |
| apw | ppisati, i did have to fix a couple of commit texts on the first one, so you may find its a rebase for you to continue | 14:47 |
| ppisati | ok | 14:47 |
| ppisati | from now, i'm slightly modifying the commit i cherry pick | 14:47 |
| ppisati | i'm adding the CVE $id in the commit line | 14:48 |
| apw | its most useful on the s-o-b area, as a CVE-NNN-MMM line | 14:48 |
| ppisati | so when i do a log --online i can catch the cve <-> commit relationship | 14:48 |
| apw | ie on its own line down the bottom, as the tooling finds it | 14:48 |
| apw | some people do put it on the end of the subject line too , CVE-NNN-MMM | 14:48 |
| ppisati | so i'll add there too | 14:49 |
| ppisati | yep, that's what i like | 14:49 |
| ppisati | anyway, i'll put in the subject and bottom commit msg too | 14:49 |
| apw | ack sounds fine. the table is looking much better now | 14:49 |
| ppisati | btw, yesterday i pushed 2 ti-omap4 tree | 14:49 |
| ppisati | maverick and natty | 14:49 |
| apw | ppisati, i've applied all three of the pushed you sent i beleieve | 14:49 |
| ppisati | did you review both already? | 14:49 |
| ppisati | ok | 14:49 |
| apw | all reviewed and pushed | 14:50 |
| apw | email reply in flight | 14:50 |
| ppisati | ooook | 14:50 |
| * apw is assuming oooook means a long OK | 14:51 | |
| apw | rather than the OOOOK (the noise a monkey makes) which often mean something bad has happened | 14:51 |
| apw | ppisati, that looks so much better on the matrix :) excellent | 14:52 |
| apw | kees, will be pleased | 14:52 |
| * ppisati never heard a monkey acking something :) | 14:56 | |
| apw | ogasawara, ok my two tiny changes pushed ... see if that builds for you ... note that it will only do so on tangerine | 14:58 |
| apw | ogasawara, once i know the version-deps required i will get them added | 14:58 |
| ogasawara | apw: ack, will kick on off now | 14:58 |
| apw | ogasawara, one of those half days of work which lead to 3 lines of change | 14:58 |
| ogasawara | heh | 14:59 |
| apw | when you look at the commits you will see what i mean | 14:59 |
| ogasawara | apw: I was just thinking about linux-meta now too | 14:59 |
| apw | ogasawara, yeah thats going to need some love, you gonna handle that? | 14:59 |
| ogasawara | apw: not sure yet what changes are required there ... | 14:59 |
| ogasawara | apw: yep, was gonna start tackling that now | 14:59 |
| apw | i am guessing we just lose a digit | 14:59 |
| bjf | smb, apw, kees, w.r.t. the security test failure on the latest -proposed, the check for CONFIG_DEBUG_RODATA on the virtual flavour is failing | 15:36 |
| bjf | smb, apw, kees, it looks like this is not enabled for that flavour on purpose | 15:36 |
| bjf | smb, apw, kees, I see code in "enforce" that seems to confirm that | 15:37 |
| bjf | smb, apw, kees, is this truly "by design" or not and a question that maybe only qa can answer is "why have we not hit this issue before"? | 15:38 |
| kees | bjf: right, I'm curious as well. wasn't it enabled in -virtual prior to natty? | 15:38 |
| sconklin | bjf, kees, apw https://bugs.launchpad.net/ubuntu/+source/linux/+bug/772096 | 15:38 |
| ubot2 | Ubuntu bug 772096 in linux "linux: 2.6.38-9.43 -proposed tracker" [Medium,Fix committed] | 15:38 |
| sconklin | for reference | 15:38 |
| bjf | smb, apw, kees, there is the following commit: | 15:39 |
| bjf | UBUNTU: Temporarily disable RODATA for virtual i386 | 15:39 |
| bjf | 15:39 | |
| bjf | Setting to RO was ok, but the whole patchset seems to cause | 15:39 |
| bjf | i386 EC instances to panic on boot when setting the kernel data | 15:39 |
| bjf | to read-only and no-execute. So while there is no proper fix | 15:39 |
| bjf | found disable this in the i386 virtual flavour. | 15:39 |
| bjf | 15:39 | |
| * kees notes the "temporarily" bit. :) | 15:39 | |
| bjf | yes | 15:40 |
| kees | afaik, upstream fixed all those problems a while ago while the CONFIG_DEBUG_SET_MODULE_RONX patchset was shaking out | 15:40 |
| kees | bjf: so, I would say it's not a regression from release, but it's a regression from maverick and should get fixed (without blocking SRU) | 15:43 |
| bjf | hggdh, ^ can you comment on why we had not picked up this issue before? | 15:43 |
| kees | bjf: afaik, qa does not test devel kernels. | 15:43 |
| bjf | kees, we had been told at different times that qa resources were unavailable for sru testing because they were focused on devel | 15:44 |
| * sconklin facepalms | 15:44 | |
| hggdh | I am getting very confused | 15:45 |
| kees | bjf: haha, yeah, good point. :) | 15:45 |
| bjf | hggdh, how can i clear up your confusion? | 15:45 |
| bjf | hggdh, or add to it? | 15:45 |
| hggdh | bjf, we have been running the QRT tests since the beginning; this specific test (test-kernel-security) has run since then. | 15:46 |
| hggdh | bjf, heh | 15:46 |
| hggdh | all the results are saved, together with the logs | 15:46 |
| bjf | hggdh, why are we only seeing the failure now | 15:46 |
| bjf | ogasawara, ^ you probably want to see this | 15:47 |
| hggdh | bjf, right now, without looking at the past logs I cannot comment | 15:47 |
| bjf | hggdh, ok, well, we know why it is failing, would be good to know how we missed it for so long | 15:48 |
| hggdh | bjf, kees, on the 'testing devel kernels': I think we should do it, and not restrict kernel testing to SRU | 15:48 |
| sconklin | next question - is this worth holding up the natty update that's in process now? We're already tossing the one that's in proposed, so I'd like to keep moving forward with the replacement for it. | 15:48 |
| bjf | hggdh, that statement implies that we do not test devel kernels, is that true? | 15:48 |
| bjf | sconklin, seems like this has been an issue for a while, i'd say don't hold it up | 15:49 |
| kees | sconklin: I do not think this should hold up this natty update. | 15:49 |
| kees | sconklin: from earlier: | 15:49 |
| kees | 14:43 < kees> bjf: so, I would say it's not a regression from release, but it's a regression from maverick and should get fixed (without blocking SRU) | 15:49 |
| hggdh | bjf, the above statement means we -- QA -- never ran the kernel tests we have for SRU on the devel kernels | 15:49 |
| sconklin | ack thanks | 15:49 |
| bjf | hggdh, good to know, thanks | 15:50 |
| sconklin | double facepalm | 15:50 |
| * sconklin weeps | 15:50 | |
| hggdh | sconklin, a question -- the fix to disable RODATA on i386 is one of the fixes for maverick kernel that failed? | 15:53 |
| sconklin | If you mean are we respinning this kernel anyway for another cycle, the answer is yes. But - we've already done most of the prep and would have to toss some work to go back and incorporate the fix | 15:54 |
| hggdh | sconklin, no, the point is this fix was _introduced_ on this kernel spin, am I correct? | 15:55 |
| sconklin | No, I don't think so. | 15:55 |
| sconklin | one sec while brad finds it ;) | 15:56 |
| pgraner | bjf, sconklin, while qa was focusing on devel testing it was not kernel... qa has never tested dev kernels, now that will be changing in the future. | 15:56 |
| ogasawara | apw: amd64 test build (all flavours) passes on tangerine | 15:59 |
| * ogasawara has to bail for dentist, back in a bit | 15:59 | |
| hggdh | sconklin, bjf: at least at 2.6.35-27.48 CONFIG_RODATA was still enabled | 15:59 |
| apw | ogasawara, nice thanks | 15:59 |
| * ppisati is the arm meeting - back in a bit | 15:59 | |
| bjf | sconklin, this change came in 2.6.38.0 | 16:00 |
| bjf | hggdh, ^ | 16:00 |
| bjf | sconklin, hggdh, i misread git, that should be 2.6.38.1.27 | 16:01 |
| hggdh | bjf, only on the 2.6.38 kernel? | 16:04 |
| bjf | hggdh, well, that means that it came in during the natty dev cycle when we picked up the .38 kernel | 16:05 |
| hggdh | bjf, OK, this is why we never saw it | 16:05 |
| hggdh | bjf, and this is another reason why the QRT tests must be kept up-to-date | 16:05 |
| hggdh | the QRT cannot be looked as usual QA tests, they must try to keep up-to-date | 16:06 |
| bjf | hggdh, i still disagree with you and this is not a case of needing to stay up-to-date | 16:14 |
| bjf | hggdh, this is a perfect case of everyone not being on the same page w.r.t. knowing what kernel tests are actually run during development | 16:15 |
| hggdh | bjf, OK. I will not get back to this | 16:16 |
| ppisati | the usb regression we had in oneiric, was it strictly usb3 related or did it screw usb in general? | 16:35 |
| ppisati | uhm xhci only seems... | 16:36 |
| herton | ppisati: yep, only xhci/usb3 | 16:37 |
| ppisati | it seems we lost usb on omap3 with 2.6.39... | 16:50 |
| herton | ppisati: ah sorry, on natty we had a report xhci/usb3 regression on latest stable, on oneiric dunno | 16:52 |
| * ppisati is trying it out... now... | 16:53 | |
| lamont | sconklin: you'll be happy to know that the non-pae kernel is just as broken | 17:00 |
| sconklin | lamont: I;m not sure happy is the operative word | 17:00 |
| lamont | consistency. for my next trick, I'll fetch your test kernels | 17:01 |
| * lamont reboots his router again | 17:01 | |
| lamont | well, in a couple minutes | 17:01 |
| sconklin | lamont: based on the results from those two I hope we can bisect this within about 4 tries | 17:01 |
| lamont | nice | 17:02 |
| sconklin | if they both pass or both fail, it's going to take longer | 17:02 |
| lamont | heh | 17:04 |
| * ppisati -> out for a walk... | 17:26 | |
| sconklin | smb: still here? | 20:46 |
| === yofel_ is now known as yofel | ||
| ppisati | sconklin: IIRC he was off today (and tomorrow) | 21:05 |
| sconklin | ppisati: ok, thanks! | 21:06 |
| === Sarvatt_ is now known as Sarvatt | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!