[08:26] <zyga> what is the best way to detect a genuine ubuntu kernel?
[08:26] <zyga> vs some other kernel?
[08:43] <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
[09:19] <zyga> apw: cloud providers often boot a different kernel 
[09:20] <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:21] <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:22] <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:23] <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:24] <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:25] <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:26] <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:27] <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:28] <zyga> this is mozilla firefox vs iceweasel issue
[09:30] <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:31] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <zyga> but we did see ancient / or current but heavily modified kernels as the norm
[09:38] <zyga> and they all disable security
[09:39] <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:40] <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:41] <zyga> I think so as well
[09:41] <apw> and you can compare it against published versions in launchpad easily enough
[09:42] <zyga> thank you apw, I think I can keep myself busy for a while :")
[11:34] <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:38] <apw> kaynemo, do you have the appropriate meta packages installed or did you hand install that change
[11:39] <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:40] <apw> kaynemo, which driver is used when it does work
[11:42] <kaynemo> how to check that ?
[11:44] <apw> ls -l /sys/class/net/wlp3s0/device/driver
[11:44] <apw> that sort of thing
[11:49] <kaynemo> cant find file or directory
[11:50] <apw> kaynemo, you did sub in an appropriate device right ?  and on the working kernel
[11:51] <kaynemo> well yeah
[11:51] <apw> well if that doesn't exist, then hmm, but lsmod and guess
[11:59] <kaynemo> lsmod is a long list and I can't find the network one
[12:07] <kaynemo> lspci and find command lead to r8169 driver
[12:17] <kaynemo> bump
[12:56] <kaynemo> ummm.... anyone to comment on what happens with the ethernet on the 4.4.0-63-powerpc64-smp kernel ?
[12:58] <apw> kaynemo, hmmm
[12:59] <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 )))
[13:07] <apw> kaynemo, nothing obvious in teh delta from -62 ... -63 so ... thats odd ...
[13:08] <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:12] <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:33] <apw> kaynemo, ta
[13:43] <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:46] <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:47]  * 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:48] <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:49] <apw> rtg, yep, there is an artifacts.tar.gz thing with all sorts of crapola in it
[13:50] <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:51] <tseliot> apw: oh, the error looks familiar, thanks
[14:22] <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:26] <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:28] <tseliot> rtg: I going to brute force that into building, so it shouldn't really be a problem any more anyway ;)
[14:35] <tseliot> rtg: by doing this http://paste.ubuntu.com/24034067/
[14:35] <tseliot> the cast is probably useless
[14:36] <apw> tseliot, that is "interesting"
[14:36] <apw> tseliot, but very sensible
[14:36] <tseliot> apw: heh, it's a temporary workaround
[14:37] <apw> tseliot, what does the double cast even mean in that context
[14:38] <apw> anyhow, whatever, it isn't your code
[14:39] <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:40] <tseliot> yes, I know... :D
[14:40] <apw> tseliot, anyhow thanks for looking ... appreciated
[14:41] <tseliot> apw: you're welcome ;)
[14:44] <tseliot> I'm going to test (using virtualbox) and upload
[14:45] <apw> tseliot, ack ta
[15:16] <tseliot> ...and no internet connection from virtualbox...
=== 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