[00:13] <lotuspsychje> good morning to all
[00:16] <pauljw> lotuspsychje :)
[00:16] <daftykins> happy new year sir \o
[00:16] <lotuspsychje> hey pauljw & daftykins
[00:16] <lotuspsychje> happy new year 2018 to you guys :p
[00:17] <lotuspsychje> best of luck & a great health
[00:17] <pauljw> same to you guys
[00:17] <lotuspsychje> and more ubuntu lol
[00:17] <pauljw> always...
[00:24] <daftykins> :)
[01:00] <lotuspsychje> oO
[01:00]  * lotuspsychje doesnt like ping timeout
[01:10] <lotuspsychje> hi FruitView
[01:27] <lotuspsychje> !keyring
[01:27] <lotuspsychje> !seahorse
[01:28] <lotuspsychje> dax: we have a trigger about that?
[01:28] <dax> not that i know of
[01:28] <lotuspsychje> lemme see if theres a wiki
[01:31] <lotuspsychje> cant find an ubuntu one dax
[01:31] <lotuspsychje> https://wiki.gnome.org/Projects/GnomeKeyring
[01:32] <dax> really don't need a factoid for everything, especially if it's just gonna be a link to whatever's in Google
[01:33] <dax> I'm really averse to the tendency (and I'm not saying this is one you have, I'm generally commenting) of relying heavily on ubottu's general factoids in lieu of hand-written targeted answers
[01:34] <lotuspsychje> allright no sweat
[01:34] <lotuspsychje> its just a question we see alot passing
[01:35] <dax> is there a webpage (or a oneliner that fits in a factoid) that actually solves the question, rather than answering "this is what a keying is"?
[01:35] <dax> (i assume the question is the "Your keyring was not unlocked at login." problem)
[01:35] <lotuspsychje> yeah
[01:35] <lotuspsychje> so users understand that part of enter password or leave blank
[01:45] <lotuspsychje> http://ubuntuhandbook.org/index.php/2013/07/disable-unlock-login-keyring-ubuntu-13-04/
[01:45] <lotuspsychje> cant find new stuff
[06:14] <EriC^^> morning all
[07:11] <lordievader> Good morning
[07:12] <lordievader> BluesKaj: I suppose Ubuntu does. It used to anyways, not sure if it still has one.
[07:12] <lordievader> Or how it is called these days.
[07:19] <ducasse> good morning all
[07:29] <lordievader> Hey Dducasse , How are you today?
[07:40] <ducasse> i'm good lordievader, thanks - how are you?
[07:40] <ducasse> had coffee yet? :)
[07:45] <lordievader> Doing good hear, just ordered a pair of speakers.
[07:46] <lordievader> Err, no tea. Found out I'm out of coffee.
[07:51] <ducasse> tea is good, i'm on coca cola here. what kind of speakers?
[07:55] <lordievader> These http://www.jamo.com/products/s622
[12:11] <BluesKaj> Hey folks
[12:29] <BluesKaj> lordievader, that R13ose guy doesn't always give important details about his problems...he's constantly doing things of which he has no idea of the consequences...dealt with him a few times before
[12:39] <lordievader> Yes, I know.
[12:42] <BluesKaj> lots of hand holding
[12:49] <lordievader> With the occasional "let me do this, crash".
[12:50] <BluesKaj> yup
[12:55] <pauljw> hi everyone
[12:59] <BluesKaj> '
[12:59] <BluesKaj> 'Morning pauljw
[12:59] <pauljw> hey BluesKaj :)
[13:01] <BluesKaj> daylight in the swamp here, and it's snowing
[13:26] <pauljw> snowing in swamp? BluesKaj, sounds like fun.
[13:28] <BluesKaj> yeah, it's light fluffy stuff that doesn't really amount to much
[13:29] <EriC^^> good afternoon everyone
[13:29] <BluesKaj> Hey EriC^^
[13:31] <EriC^^> hey BluesKaj
[13:31] <EriC^^> how are you?
[13:32] <BluesKaj> Good here EriC^^, how about you/
[13:32] <EriC^^> good thanks
[13:32] <BluesKaj> ?
[13:32] <pauljw> hi EriC^^
[13:32] <EriC^^> hi pauljw how's it going?
[13:33] <pauljw> good thx.  :)
[13:33] <EriC^^> :)
[18:36] <lotuspsychje> good evening to all
[18:38] <lotuspsychje> http://www.omgubuntu.co.uk/2018/01/amazon-brings-linux-distro-enterprise-making-red-hat-worry
[18:47] <lotuspsychje> http://www.linuxandubuntu.com/home/10-reasons-why-linux-is-better-than-windows
[18:49] <lotuspsychje> JanC: i bypassed belgian EID firefox 57 issue by adding the certificate, works now
[18:59] <pauljw> hey lotuspsychje :)
[18:59] <lotuspsychje> hey pauljw
[19:02] <lotuspsychje> hey Bashing-om
[19:03] <Bashing-om> hey lotuspsychje :) ,, been a good session ?
[19:03] <lotuspsychje> just joined cant tell, currently active!
[19:12] <Bashing-om> lotuspsychje: 2, just getting settled in . We be active :)
[20:41] <Bashing-om> Outside chore .. back soonest :(
[20:41] <lotuspsychje> breath deep :p
[20:41] <pauljw> :)
[20:44] <lotuspsychje> !info linux-image-generic artful
[20:44] <nicomachus> lotuspsychje: kernels up to 14.9 and 14.10?
[20:45] <nicomachus> 4.14?
[20:45] <lotuspsychje> er yeah
[20:45] <lotuspsychje> oh wait holdon
[20:45] <lotuspsychje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147
[20:45] <nicomachus> I imagine that the 4.4 kernel will get updated too. surely not just 4.14
[20:46] <lotuspsychje> 4.14.9
[20:46] <lotuspsychje> and 4.14.10
[20:49] <nicomachus> I've had a ton of updates this morning that look like library updates or something. wondering if that's related.
[20:57] <lotuspsychje> nicomachus: not sure im on bionic
[20:57] <lotuspsychje> TJ-: !qemu real outdated 2011
[20:58] <lotuspsychje> !qemu
[20:58] <dax> we're gonna need a KPTI factoid, way these questions are going
[20:59] <lotuspsychje> dax: good idea
[20:59] <dax> that's what, three just in the scrollback on my screen
[21:01] <TJ-> dax: it's a major issue, for sure. "KAISER a.k.a Kernel Page Table Isolation is a bug in Intel CPUs since around 2006 which leaks information about kernel data structures into userspace and potentially allows attackers to execute code with kernel privileges"
[21:01] <dax> !usn
[21:02] <dax> "!kpti is <reply> The Linux community is working on a patchset for a hardening technique named KPTI that addresses recently-disclosed issues in some processors. Once finished, updates addressing this issue will be released through the normal Ubuntu security update process. See http://www.ubuntu.com/usn if you are interested in receiving all Ubuntu security update notifications."
[21:02] <TJ-> dax: that's my best non-techy description for now. It's not clear (yet) if it does allow direct privilege escalation but based on the embargo and scramble to release patches it seems likely
[21:02] <dax> s/some processors/many processors/
[21:02] <TJ-> Make clear it does NOT affect AMD CPUs
[21:03] <TJ-> Intel CPUs from the Core micro-architecture onwards are affected
[21:03] <nicomachus> TJ-: I like the other name better but it's not mentionable on this channel. haha
[21:03] <dax> which of our non-x86 supported targets does it affect?
[21:03] <alkisg> I wonder if that will get backported to 16.04 non-hwe kernel, i.e. 4.4... It would be nice to have an insecure but faster kernel available :D
[21:03] <dax> alkisg: iirc you can turn off the KPTI patchset with a kernel cmdline option, but not 100% sure, i've read a lot recently
[21:04] <TJ-> dax: it's only Intel x86 for this one
[21:04] <alkisg> Ah, that'd be perfect then
[21:04] <alkisg> ty
[21:04] <TJ-> dax: either "nopti" or "pti=off"
[21:04] <dax> TJ-: are the ARM patches people keep going on about preventative?
[21:04] <nicomachus> alkisg: i'd rather have it get fixed on a release that's supported for another 3.5 years...
[21:04] <TJ-> dax: they're a slightly different issue to this one, but with a similar result
[21:04] <TJ-> for ARM64
[21:05] <alkisg> nicomachus: if there's a switch for it, yeah, I'd love to have it. Although 16.04 comes with 4.10 nowadays, 4.4 is the non-hwe version
[21:05] <nicomachus> yea I'm still on 4.4 here
[21:05] <TJ-> e.g. revealing the kernel's randomised base/load address
[21:05] <nicomachus> -104
[21:05] <nicomachus> dax: please use Forcefully Unmap Complete Kernel With Interrupt Trampolines
[21:05] <dax> "!kpti is <reply> The Linux community is working on a patchset for a hardening technique named KPTI that addresses recently-disclosed issues in Intel processors. Once finished, updates addressing this issue will be released through the normal Ubuntu security update process. See http://www.ubuntu.com/usn if you are interested in receiving all Ubuntu security update notifications."
[21:05] <dax> nicomachus: ah, is that what that stood for
[21:06] <dax> "!kpti is <reply> The Linux community is working on a patchset for a hardening technique named KPTI that addresses recently-disclosed issues in Intel processors. Once finished, updates containing this patchset will be released through the normal Ubuntu security update process. See http://www.ubuntu.com/usn if you are interested in receiving all Ubuntu security update notifications."
[21:06] <TJ-> ah, kernel devs and their naming conventions, such wags!
[21:06] <alkisg> How old intel CPUs does it affect? E.g. the first dual cores? Or even P4's?
[21:06] <dax> alkisg: Core onwards, TJ- just said
[21:06] <TJ-> alkisg: ^^
[21:06] <alkisg> Sorry didn't see that. Whoops, that's a very big range
[21:07] <alkisg> And are we expecting a 10% slowdown?
[21:07] <nicomachus> TJ-: I think they got a little frustrated trying to fix it. :D
[21:07] <dax> further wording suggestions? (also, any aliases?)
[21:07] <dax> alkisg: it's workload-dependent. I have 4.15-rc6 on my machine right now which has it, and I don't notice any slowdown
[21:07] <lotuspsychje> https://www.phoronix.com/scan.php?page=article&item=linux-more-x86pti&num=1
[21:07] <dax> because my CPU isn't pegged, like most people's aren't
[21:07] <alkisg> Nice to hear, ty :)
[21:08] <nicomachus> dax: I'm worried about the slowdown
[21:08] <lotuspsychje> cant find official ubuntu kpti articles yet
[21:08] <nicomachus> alkisg: I've heard more along the lines of 5-30(!!)% slowdown
[21:08] <alkisg> Ouch
[21:08] <dax> lotuspsychje: afaik there aren't any
[21:08] <TJ-> as far as I've been able to tell from my research reading Intel whitepapers this bug is in the Core micro-architecture's Smart Memory Access technolgy, specifically I think the speculative reordering of data loads before stores, which can cause page exceptions and reveal which addresses the kernel is using
[21:09] <dax> TJ-: yeah, that matches what I've seen so far (which is significantly less in-depth than your reading, I expect, but isn't just pop media)
[21:09] <TJ-> lotuspsychje: it's under embargo, everything you're hearing is intelligent 'speculation' based on patches and some published papers
[21:09] <lotuspsychje> https://nakedsecurity.sophos.com/2018/01/03/fckwit-aka-kaiser-aka-kpti-intel-cpu-flaw-needs-low-level-os-patches/amp/
[21:09] <dax> and I'm not putting speculation in factoids, and that includes performance numbers
[21:09] <nicomachus> "These KPTI patches move the kernel into a completely separate address space, so it's not just invisible to a running process, it's not even there at all. Really, this shouldn't be needed, but clearly there is a flaw in Intel's silicon that allows kernel access protections to be bypassed in some way."
[21:09] <nicomachus> "The downside to this separation is that it is relatively expensive, time wise, to keep switching between two separate address spaces for every system call and for every interrupt from the hardware. These context switches do not happen instantly, and they force the processor to dump cached data and reload information from memory. This increases the kernel's overhead, and slows down the
[21:09] <nicomachus> computer."
[21:10] <TJ-> Xen have an embargo on XSA-253 due to lift tomorrow lunchtime UTC which is probably it: https://xenbits.xen.org/xsa/
[21:10] <dax> !kpti
[21:10] <dax> !-kpti
[21:11] <TJ-> if you want to read Intel's whitepaper on Smart Memory Access I have it here: http://iam.tj/projects/Intel-SmartMemoryAccess.pdf
[21:11] <nicomachus> TJ-: looks like someone found an exploit: https://twitter.com/brainsmoke/status/948561799875502080
[21:11] <dax> (feel free to highlight when the situation changes or if you have additional alias suggestions. going afk for a little bit)
[21:11] <nicomachus> dax: I suppose if you really wanted, you could link this: https://lkml.org/lkml/2017/12/4/709
[21:11] <TJ-> nicomachus: yes, that's it
[21:22] <lotuspsychje> nice find nicomachus
[21:25] <JanC> lotuspsychje: you mean you manually added the "security device" or whatever they call it?
[21:25] <JanC> in Firefox 58 there should be an "easy way" to add it again
[21:25] <lotuspsychje> https://newsroom.intel.com/news/intel-responds-to-security-research-findings/
[21:26] <lotuspsychje> JanC: the belgian ROOT certificate upload to firefox options/certificates
[21:27] <lotuspsychje> JanC: libbeid...so
[21:27] <lotuspsychje> and now its working
[21:28] <JanC> that's more than only the root cert
[21:28] <lotuspsychje> yeah, the security device
[21:29] <lotuspsychje> JanC: anyway its working now
[21:30] <JanC> Wouter wrote a patch to add a function that allows adding security devices to the new extension API for Firefox, but they didn't want to include it into 57, but it should be in 58
[21:30] <lotuspsychje> cool
[21:31] <lotuspsychje> ive tested on 57 + bionic devel
[21:37] <lotuspsychje> nite nite guys
[21:37] <lotuspsychje> the whole web full of that kpti bug
[21:39] <JanC> from what I've read (which is not much yet), the slowdown from the patch for the Intel issue mostly affects systems that need to do lots of kernel/userspace context switches
[21:40] <dax> yes, that's where the slowdown is
[21:41] <dax> so you'll be more or less affected depending on whether your workload 1) does lots of context switches (not including VDSO), 2) runs your CPU at 100%
[21:41] <dax> so most people, even most gamers, won't even notice
[21:42] <JanC> not sure how much context switches they need for graphics...
[21:42] <JanC> applications that do a lot of I/O would be heavily affected probably
[21:42] <dax> if they're CPU-bound
[21:43] <dax> I mean, I'm looking at this from the point of view of desktop users + people running VMs that aren't pegged
[21:43] <dax> and they'll probably see somewhat lower numbers if they run a benchmark, and not notice otherwise
[21:44] <JanC> we'll see, I guess
[21:44] <TJ-> JanC: also for interrupts and page-fault handling
[21:45] <JanC> anything using a tight I/O polling loop would be affected (but that's probably not a good design anyway)
[21:46] <dax> (which leads to the more general discussion of how modern Intel CPUs are all ridiculous overkill for consumer workloads, hence the switch to competing based on wattage etc. instead of Ghz)
[21:46] <TJ-> Intel seem to be in denial over it "...when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operating as designed" and trying to imply this isn't unique to them, which explains why the AMD patch has made it clear they're not affected
[21:46] <JanC> well, it depends what you want to do  :)
[21:47] <dax> hint: whatever crazy CPU-bound "what you want to do" you just came up with isn't what i meant by "consumer workloads"
[21:47] <TJ-> "operating as designed" in this case is == "operating insecurely as designed"
[21:48] <dax> "Intel believes its products are the most secure in the world" lol
[21:51] <TJ-> dax: yes, it's such tosh it's obvious they're in denial and scrambling for damage limitation over responsible disclosure :)
[21:53] <JanC> dax: some webpages manage to permanently peg a CPU core to 100% quite easily  :)
[21:54] <JanC> (but you won't solve that with a faster CPU)
[21:54] <dax> i wouldn't know. my workplace installs adblocker automatically. my home stuff is all adblockered. and i don't go to crappy gaming websites.
[21:55] <JanC> oh, even Twitter & crap like that can do that if you leave a page open long enough...
[21:56] <JanC> it's just bad JavaScript programming usually
[22:16] <TJ-> I like umatrix since it shows the 3rd-party domains and blocks them by default, but makes it easy to enable selected resources either temporarily or permanently
[22:32] <dax> https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
[22:40] <TJ-> so, the reason AMD say they are not affected is the proof-of-concept allows a read but without crossing the privilege boundary, whereas Intel CPUs do
[22:41] <dax> *nod*
[22:41] <dax> didn't read much past the list of PoCs yet
[22:41] <TJ-> and PoC #2 affects them only if " If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU"
[22:41] <dax> any idea whether Ubuntu enabled that?
[22:42] <nacc> CONFIG_BFP_JIT=y in the 17.10 kernel
[22:42] <nacc> i'm fairly sure all distros enable it, but not 100%
[22:42] <TJ-> /boot/config-4.4.0-105-lowlatency:CONFIG_HAVE_BPF_JIT=y
[22:42] <dax> nice
[22:42] <nacc> it's a fairly significant performance difference for that particular toggle (iirc)
[22:46] <TJ-> interesting that the hyper-threading is one vector to exploitation too since that's a single core and therefore it's possible to have 1 thread doing injections and the other testing if they are successful
[22:48] <TJ-> blimey! design-gotchya 101: "...Given that branch prediction also must be very fast, we concluded that it is likely that the update function of the history buffer left-shifts the old history buffer, then XORs in the new state"
[22:48] <TJ-> that's in reference to the prediction history buffer, which is ~26 entries deep
[22:50] <nacc> TJ-: nice
[22:56] <TJ-> oh wonderful: "...  It would be interesting to see whether attacks against more advanced JIT engines with less control over the system are also practical - in particular, JavaScript engines."
[22:56] <nacc> TJ-: yeah, i think the first matter of business is disabling JS :?
[22:56] <nacc> :/ rather
[22:57] <dax> !kpti
[22:57] <dax> !-kpti
[22:58] <nacc> dax: thx
[23:01] <TJ-> "every Intel processor which implements out-of-order execution ... affected ... effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013"
[23:05] <TJ-> No wonder this is making waves, they've a PoC working using Javascript to escape browser sandboxing using the spectre technique
[23:05] <TJ-> not a problem for servers of course (err, hello, node.js)
[23:08] <JanC> does anyone know if CPUs from other brands are affected by the Intel issue or similar?
[23:09] <dax> it's discussed in the FAQ on  https://spectreattack.com/
[23:12] <TJ-> PoC code in the PDF in 124 SLOC
[23:48] <JanC> the FAQ isn't entirely clear, and elsewhere there is conflicting information...
[23:50] <TJ-> JanC: right now there are only proofs-of-concept on Intel hardware. Spectre paper says they think that'll affect AMD Ryzen too but they didn't actually test it
[23:51] <TJ-> Interestingly, AMD claim that their prediction/speculative execution is using a neural-network that learns and adapts and is/should therefore be mostly immune to some of these attacks, or be very unpredictable
[23:51] <TJ-> (thus making it hard to exploit reliably)
[23:52] <TJ-> which possibly infers that AMD systems with longer up-times are less susceptible
[23:52] <JanC> might also depend on how predictable things actually are  :)
[23:55] <TJ-> It's certainly a watershed moment; lots of admins going to be burning midnight oil as the saying goes
[23:56] <JanC> well, there is no solution for Spectre AFAICT, so no point trying to fix that (certainly not as an admin)
[23:57] <TJ-> It could be this causes a major pause in the rush to 'cloud'
[23:57] <JanC> yeah
[23:57] <TJ-> since these are really serious for shared-tennant services
[23:58] <JanC> although that might depend on how mass media describe it (as the people who decide on using the cloud or not might often not be technical people...)