| zyga | what is the best way to detect a genuine ubuntu kernel? | 08:26 |
|---|---|---|
| zyga | vs some other kernel? | 08:26 |
| apw | zyga, from what context, the only absolute way is to confirm the kernel binary is not modified relative to the package and the package is from the official archive | 08:43 |
| zyga | apw: cloud providers often boot a different kernel | 09:19 |
| zyga | apw: we may have the package on disk but it is not used | 09:20 |
| zyga | apw: I was wondering if we could put something into our kernel that we could ask from userspace for | 09:20 |
| zyga | apw: e.g a dummy module that says "this is a certified Linux kernel from Caonical" | 09:20 |
| apw | zyga, how would you guarentee that the cloud provider did not also dothat | 09:20 |
| apw | in order to not seem different from ours | 09:20 |
| zyga | apw: so that even if they fake that (on purpose) we can have a legal standing that they cannot do thus | 09:20 |
| zyga | apw: and if they don't do this it is easy detect | 09:21 |
| zyga | apw: yes but if they do it on purpose we can do other things | 09:21 |
| zyga | apw: I'm after casual kernel replacement, not mailciou actor | 09:21 |
| zyga | *malicious | 09:21 |
| zyga | apw: e.g. a module that adds a file to sysfs that says "this is a certified Linux kernel, designed for Ubuntu, from Canonical" | 09:22 |
| apw | zyga, i assume a non-malicious kernel in that context would have a non-standard version number | 09:22 |
| zyga | apw: yes but what is our version number? | 09:22 |
| zyga | apw: what can I check for in userspace to easily know "certified kernel" | 09:23 |
| apw | zyga, launchpad knows what our officially released version numbers are, and they have a standard form | 09:23 |
| zyga | apw: complicated | 09:23 |
| apw | anyone modifying the kernel has to avoid our namespace | 09:23 |
| zyga | apw: I need to make a spot decision when I see !ubuntu kernel | 09:23 |
| zyga | wait, what is our namespace? | 09:23 |
| zyga | I don't see any ubuntu / canonical words in 'uname -a' | 09:24 |
| apw | the problem is anything we do in our packaging would likely be copied to the cloud-vendor kernel | 09:24 |
| apw | so if we add something saying it is certified, theirs will also say that | 09:25 |
| zyga | that's much better | 09:25 |
| apw | ? | 09:25 |
| zyga | because then we can use trademark law to smite such use | 09:25 |
| zyga | right now we don't have any way to detect misuse | 09:26 |
| zyga | or a way to react really | 09:26 |
| zyga | we'd be fixing one of those at least | 09:26 |
| apw | hmmm | 09:26 |
| zyga | + if they read the kernel patches from us we could ensure the module has very clear language | 09:26 |
| zyga | that the intent of the module is to signify a certified canonical kernel | 09:26 |
| zyga | and it should not be copied without an agreement with canonical | 09:26 |
| zyga | as that would signify trademark violation | 09:27 |
| apw | i am not sure our licencing would let us do that | 09:27 |
| zyga | which licensing? | 09:27 |
| zyga | we keep saying you get to call it ubuntu if it is unmodified | 09:27 |
| apw | that this is a gpl 2 package | 09:27 |
| zyga | that's fine | 09:27 |
| zyga | they _can_ legally include that module | 09:27 |
| zyga | but they cannot legally use the trademark | 09:27 |
| zyga | this is mozilla firefox vs iceweasel issue | 09:28 |
| apw | but are we fixing the right issue | 09:30 |
| apw | you want to know the running kernel is (assuming non-malicious actors) | 09:30 |
| apw | from us. why is the fact it is in a signed package from us not the right thing | 09:30 |
| apw | that is how we assert that things came from us | 09:31 |
| apw | so you can safely consume them | 09:31 |
| zyga | apw: hmmm, because the package is not a running thing, I just booted linode instance of 16.04 and it has our kernel installed | 09:31 |
| zyga | but not in use | 09:31 |
| zyga | the VM gets booted with an external kernel | 09:32 |
| apw | right but you can tell which kernel is running | 09:32 |
| zyga | I don't think that looking at the package can ehlp | 09:32 |
| apw | matching its version number | 09:32 |
| apw | if you don't have a package matching it, your are not ubuntu | 09:32 |
| apw | if you don't have a package signed by us matching it, you are not ubuntu | 09:32 |
| zyga | another problem is that this would not work in core world easily | 09:32 |
| zyga | (e.g. packaging formats differ) | 09:33 |
| zyga | I'd much rather ask the kernel about itself | 09:33 |
| apw | what are we going to be gating on this informaito | 09:33 |
| zyga | I want to include this in the error report we're sending to daisy.ubuntu.com | 09:34 |
| zyga | along with whatever kernel version we get | 09:34 |
| zyga | we suspect there's a large population of errors caused by replaced kernels on cloud systems | 09:34 |
| zyga | I'd really like that trivial (GPL2) module that just uses our trademarks | 09:34 |
| zyga | even if people can spoof that | 09:35 |
| apw | so we can tell if people are using legit version numbers on our end if this is daisy | 09:35 |
| apw | we do that kind of thing to bin launchpad bugs for reports which are on modified kernels | 09:36 |
| apw | already. | 09:36 |
| apw | do we have a case where people are making kernels with versions that look like ours | 09:36 |
| zyga | do you have some more data about this? | 09:37 |
| apw | or is this hyperthetical attack? | 09:37 |
| zyga | ah | 09:37 |
| zyga | sorry I misread your qeustion | 09:37 |
| apw | more data? as in how we decide if things are legit? | 09:37 |
| zyga | question* | 09:37 |
| zyga | no, no; I skipped the "do" in your last statement | 09:37 |
| apw | ahh | 09:37 |
| zyga | I don't know of such kernels but I'm still making a sweep through pouplar cloud providers | 09:37 |
| zyga | but we did see ancient / or current but heavily modified kernels as the norm | 09:38 |
| zyga | and they all disable security | 09:38 |
| apw | you could probabally argue, if you were going to, that /proc/version_signature includes our trademark for this purpose | 09:39 |
| zyga | oh | 09:39 |
| zyga | that's perfect! | 09:39 |
| apw | and we use the version in there and/or the version in /proc/version to determine if this is | 09:40 |
| zyga | I didn't know about this file (I kept looking at sys) | 09:40 |
| apw | a valid kernel | 09:40 |
| apw | from us. | 09:40 |
| zyga | thanks, I think this will do! | 09:40 |
| zyga | I'll re-check what each cloud says there | 09:40 |
| apw | i am pretty sure the version in there is reliable enough for most purposes | 09:40 |
| zyga | I think so as well | 09:41 |
| apw | and you can compare it against published versions in launchpad easily enough | 09:41 |
| zyga | thank you apw, I think I can keep myself busy for a while :") | 09:42 |
| kaynemo | hello all ! upgraded to 4.4.0-63-powerpc64-smp kernel today and lost networking on ehternet (seems that module doesn't load up), rebooted to previous kernel (currently running it) and the network is just fine. Any ideas? | 11:34 |
| apw | kaynemo, do you have the appropriate meta packages installed or did you hand install that change | 11:38 |
| kaynemo | well it was the result of sudo apt-get dist-upgrade command | 11:39 |
| apw | then you have the right things installed | 11:39 |
| kaynemo | which is weird, because it will not bring up the network no matter what I do | 11:39 |
| apw | kaynemo, which driver is used when it does work | 11:40 |
| kaynemo | how to check that ? | 11:42 |
| apw | ls -l /sys/class/net/wlp3s0/device/driver | 11:44 |
| apw | that sort of thing | 11:44 |
| kaynemo | cant find file or directory | 11:49 |
| apw | kaynemo, you did sub in an appropriate device right ? and on the working kernel | 11:50 |
| kaynemo | well yeah | 11:51 |
| apw | well if that doesn't exist, then hmm, but lsmod and guess | 11:51 |
| kaynemo | lsmod is a long list and I can't find the network one | 11:59 |
| kaynemo | lspci and find command lead to r8169 driver | 12:07 |
| kaynemo | bump | 12:17 |
| kaynemo | ummm.... anyone to comment on what happens with the ethernet on the 4.4.0-63-powerpc64-smp kernel ? | 12:56 |
| apw | kaynemo, hmmm | 12:58 |
| kaynemo | it's not that I cannot live without a new kernel and all, but, you know, a) it is weird, b) reluctant to upgrade from now on ))) also curious ))) | 12:59 |
| apw | kaynemo, nothing obvious in teh delta from -62 ... -63 so ... thats odd ... | 13:07 |
| apw | kaynemo, next thing to do is file a bug against the kernel (ubuntu-bug linux) and tell me the bug number | 13:08 |
| apw | kaynemo, and i will ask one of my collegues to help you bisect it | 13:08 |
| kaynemo | thank you ! | 13:08 |
| kaynemo | will do so | 13:08 |
| kaynemo | Bug #1666209 | 13:12 |
| ubot5 | bug 1666209 in linux (Ubuntu) "PPC new 4.4.0-63-powerpc63-smp kernel kills networking" [Undecided,New] https://launchpad.net/bugs/1666209 | 13:12 |
| apw | kaynemo, ta | 13:33 |
| rtg | tseliot, we're seeing i386 ADT test failure on nVidia 375. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/i386/n/nvidia-graphics-drivers-375/20170216_141621_af1c4@/log.gz | 13:43 |
| tseliot | rtg: maybe the i386 chroot/machine has a problem? I don't see how this and the DKMS dependency thing can depend on my packages: "ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored." | 13:46 |
| tseliot | rtg: oh, bad build too, can I get the log, please? | 13:46 |
| * tseliot has no i386 hardware | 13:47 | |
| tseliot | rtg: I mean this /var/lib/dkms/nvidia-375/375.39/build/make.log | 13:47 |
| rtg | tseliot, you can install in an i386 VM which a least would give you the compile errors | 13:47 |
| rtg | tseliot, ADT doesn't keep logs like that frm an ephemeral session | 13:48 |
| apw | rtg, yes it does keep those logs | 13:48 |
| * apw files you a bug, one sec | 13:48 | |
| rtg | apw, indeed ? | 13:48 |
| tseliot | that would sure save me some time | 13:48 |
| apw | rtg, yep, there is an artifacts.tar.gz thing with all sorts of crapola in it | 13:49 |
| apw | https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-375/+bug/1666220 | 13:50 |
| ubot5 | Ubuntu bug 1666220 in nvidia-graphics-drivers-375 (Ubuntu) "nvidia-graphics-drivers-375 375.39-0ubuntu1 ADT test failure with linux 4.10.0-8.10" [Undecided,New] | 13:50 |
| apw | tseliot, ^ | 13:50 |
| tseliot | apw: oh, the error looks familiar, thanks | 13:51 |
| tseliot | apw, rtg: that build failure is weird. NVIDIA already set a test for that in their conftest.sh: http://pastebin.ubuntu.com/24034020/ | 14:22 |
| tseliot | I'm not quite sure why that would be different on i386 | 14:22 |
| apw | indeed | 14:26 |
| rtg | tseliot, I'm not gonna hold up promotion to release over that, but I'd sure like to see it fixed eventually | 14:26 |
| tseliot | rtg: I going to brute force that into building, so it shouldn't really be a problem any more anyway ;) | 14:28 |
| tseliot | rtg: by doing this http://paste.ubuntu.com/24034067/ | 14:35 |
| tseliot | the cast is probably useless | 14:35 |
| apw | tseliot, that is "interesting" | 14:36 |
| apw | tseliot, but very sensible | 14:36 |
| tseliot | apw: heh, it's a temporary workaround | 14:36 |
| apw | tseliot, what does the double cast even mean in that context | 14:37 |
| apw | anyhow, whatever, it isn't your code | 14:38 |
| tseliot | apw: it should be for the size, I think. I had the same problem when I had to call this: | 14:39 |
| tseliot | NV_SMP_CALL_FUNCTION(nv_setup_pat_entries, (void *)(long int)hcpu, 1) | 14:39 |
| apw | yeah i guess it widens it first, but uggg | 14:39 |
| tseliot | yes, I know... :D | 14:40 |
| apw | tseliot, anyhow thanks for looking ... appreciated | 14:40 |
| tseliot | apw: you're welcome ;) | 14:41 |
| tseliot | I'm going to test (using virtualbox) and upload | 14:44 |
| apw | tseliot, ack ta | 14:45 |
| tseliot | ...and no internet connection from virtualbox... | 15:16 |
| === JanC is now known as Guest41946 | ||
| === JanC_ is now known as JanC | ||
| === GoosGoarch is now known as ayan | ||
| === ayan is now known as ayan-afk | ||
| === smb` is now known as smb | ||
| === Mani is now known as Guest46494 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!