Meeting log 2013-06-27 20:00UTC

[22:03:33] <Zorry> 1.0 Toolchain
[22:03:37] <blueness> btw in real life call me Tony
[22:04:04] <Zorry> gcc 4.8.1 is in the tree and have the gcc plugin header fix
[22:04:34] <Zorry> and the piepatches have fix for ia64 and arm to make it work
[22:04:57] <blueness> Zorry, are those in 4.8.1?  because we can close that one bug
[22:05:13] <Zorry> blueness: it is in 4.8.1
[22:05:16] <blueness> nice
[22:05:49] <blueness> bug #460356
[22:05:51] <willikins> blueness: https://bugs.gentoo.org/460356 "hardened-sources-3.8.0: doesn't build with hardened GCC due to Plugin Support missing on arm"; Gentoo Linux, Hardened; UNCO; sourcepower:hardened-kernel
[22:06:16] <Zorry> not that bug
[22:06:26] <blueness> for arm?
[22:06:31] <klondike> Zorry: not fixed in 4.8.1?
[22:06:55] <Zorry> the arm thing was the ssp/pie was not enable
[22:07:34] <steev> wait what
[22:07:38] <SwifT> reading the bug subject, i can imagine that the gcc plugin header fix would resolve this one, not?
[22:07:48] <steev> what arm device is building 3.8.0 hardened sources
[22:08:15] <steev> interesting, cubox
[22:08:17] <steev> i have one of those
[22:09:29] <Zorry> blueness:  but it looks like it fixed upstream
[22:09:40] <Zorry> so you should test
[22:09:50] <blueness> Zorry, okay i will
[22:10:18] <blueness> i'm a bit confused why the two bugs are not closely related but okay ...
[22:10:25] <blueness> i'll talk to pipacs
[22:11:02] <Zorry> blueness: http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00225.html
[22:11:27] <Zorry> blueness: my fix was in the Makefile
[22:11:52] <blueness> k
[22:12:59] <Zorry> will add stack-check when i have a fix for flag-o-matic to support disable of it
[22:13:43] <klondike> Zorry: you shoulld be able to copypaste pie for example, don't you?
[22:14:14] <Zorry> we did hit some asm probs on some media libs
[22:14:41] <blueness> Zorry, just the one plugin for ffmpeg
[22:15:03] <blueness> it is amd64 asm but they used all 10 free registers leaving nothing for pie
[22:15:12] <Zorry> blueness: yes so far but we have ~14000 pakages in the tree
[22:15:16] <klondike> blueness: didn't I write a patch for it?
[22:15:31] <blueness> Zorry, i say let's hit them and throw klondike at them
[22:15:51] <klondike> works for me
[22:15:55] <blueness> klondike, yeah but ... downstream won't add it and upstream probalby wont either
[22:15:59] <blueness> so where do you go with that
[22:16:56] <blueness> Zorry, you know what, can we ask diego to do a special tinderbox run with CFLAGS="-fstack-check"?
[22:16:59] <klondike> I can convince upstream
[22:17:10] <klondike> you just caught me in a very bad day :P
[22:17:12] <blueness> Zorry, i can't imagine we will have that many
[22:17:34] <blueness> Zorry, or can you do tinderboxing on this?
[22:17:43] <Zorry> blueness: i think we can fix the pakages when we hit it
[22:17:49] <SwifT> what does -fstack-check do?
[22:17:57] <SwifT> break the build when no free registers ?
[22:18:03] <Zorry> gcc 4.8.1 is still not keyworded yet
[22:18:05] <klondike> lol
[22:19:18] <SwifT> oh, it crashes the app when it misbehaves
[22:19:21] <Zorry> SwifT:  it do some stack checks
[22:19:23] <blueness> SwifT, things like alloca can grow a stack
[22:19:32] <klondike> SwifT: http://gcc.gnu.org/onlinedocs/gccint/Stack-Checking.html
[22:19:37] <blueness> when the stack grows it carries the canary with it
[22:19:51] <Zorry> blueness: any 
[22:20:00] <Zorry> uclibc stuff?
[22:20:00] <blueness> so the canary cannot be used to check for more sophiscated attacks which grow a stack
[22:20:04] <blueness> Zorry, yes
[22:20:16] <SwifT> thx
[22:20:18] <blueness> 1) i'm continuing support of everything so far
[22:20:47] <blueness> 2) i'm adding ISA=mips64 ABI=n32 uclibc because of the new router boards that are out
[22:21:25] <blueness> 3) i've switch to gcc-4.8.0 and now 4.8.1 for mips because even though it is not keyworded, it is less hacky than gcc-4.6.3 + the hacky pie patch
[22:21:58] <blueness> 4) i'm maintaining that "fun" project of a total uclibc desktop ... not very seriously but its fun
[22:22:07] <blueness> 5) i am working on a new libc, musl
[22:22:14] <blueness> i've added preliminary profiles to the tree
[22:22:24] <blueness> but ... its not ready for human yet
[22:22:34] <blueness> its very very scawy
[22:22:37] <blueness> :)
[22:23:04] <Zorry> any one else?
[22:23:05] <blueness> nothing deep, unless you want to hear about the deep issues with how elfs are put together on mips64 ...
[22:23:39] <Zorry> next
[22:23:56] <Zorry> 2.0 Kernel and Grsec/PaX
[22:24:22] <blueness> k
[22:24:41] <blueness> first the kernel itself, there are issues with 3.8 and uefi boots
[22:24:51] <blueness> prometheanfire, can speak about that if he likes
[22:24:51] <prometheanfire> 3.[9,10]
[22:24:57] <blueness> he's been testing
[22:25:37] <klondike> blueness: I can test now that I'm on Valencia
[22:25:44] <prometheanfire> but ya, I've been testing and amd64 kernels (vanilla) running with low mem cause the kernel to hang before it's displayed any data at all
[22:25:45] <klondike> I have a UEFI box
[22:26:07] <klondike> prometheanfire: physical or virtual vms?
[22:26:11] <prometheanfire> see bug 471626
[22:26:14] <willikins> prometheanfire: https://bugs.gentoo.org/471626 "sys-kernel/hardened-sources-3.9.* fails to boot with uefi"; Gentoo Linux, Hardened; CONF; nikoli:hardened-kernel
[22:26:15] <blueness> yeah we need this testing because its the wave of the future
[22:26:27] <prometheanfire> I think this may be limited to some specific hardware, not sure about it
[22:27:12] <blueness> upstream was dismissive in that one email
[22:27:15] <prometheanfire> other people have experienced the issue as well, I'm asking that they test the kernels/configs I've provided (see http://dev.gentoo.org/~prometheanfire/bugs/471626/ ) to see if they can reproduce without the mem=300M
[22:27:18] <blueness> do you have a workaround?
[22:27:23] <prometheanfire> ya, they didn't seem to care
[22:27:48] <blueness> prometheanfire, if you remove mem=, does it work?
[22:27:54] <prometheanfire> I need to test hardened 3.9 again with the full memory to see if it boots, but I don't think it will
[22:28:05] <prometheanfire> blueness: for vanilla, yes
[22:28:33] <prometheanfire> I didn't do any repeated booting (to see if there was a specific area of memory that causes this)
[22:28:50] <prometheanfire> and that's about it
[22:29:02] <blueness> prometheanfire, is it reproduceabl in any virtual machines emulators that can emulate efi, like virtualbox?
[22:29:33] <blueness> emus can log each clock cycle to find what the hell is going on
[22:29:34] <prometheanfire> haven't tried virtualbox, but tested kvm and it's not reproducable there
[22:29:44] <prometheanfire> ya, pipacs helped me test that
[22:29:49] <blueness> yeah kvm  doesn't really have much in the way of firmware
[22:29:58] <blueness> it uses seabios or something
[22:30:03] <prometheanfire> he showed me how to test uefi on it
[22:30:08] <blueness> on kvm/
[22:30:14] <blueness> on kvm?
[22:30:17] <prometheanfire> yes
[22:30:23] <blueness> nice
[22:30:39] <blueness> i know that in minor arches you can feed it different bootloaders so yeah makes sense
[22:31:58] <prometheanfire> ya, that's all I have for that, where I currently sit, is that more testing needs to happen with vanilla kernels
[22:32:14] <klondike> prometheanfire: it also happens on non pax kernels?
[22:32:16] <prometheanfire> specifically, reproducing the issue with a vanilla kernel and without the mem= option used
[22:32:20] <prometheanfire> klondike: yes
[22:32:46] <blueness> okay, nothing more really with the kernel, just the usual issues of pressure from a fast moving vanilla and fast moving grsec/pax makes it difficult to know exactly which version to stabilize
[22:32:48] <klondike> prometheanfire: same memory amount causing the issues more or less?
[22:33:18] <prometheanfire> here's the email I sent for refrence http://bpaste.net/show/OvMOllBlsjCpABk4Y7Z6/
[22:33:32] <blueness> i put 3.8.12 back on the tree and may stabilize it to get rid of the older 3.8 whose vanilla versions have security issues
[22:33:40] <prometheanfire> blueness: thanks for that :D
[22:33:42] <klondike> Because I may know what's going on :P
[22:33:54] <prometheanfire> klondike: I don't know what you mean by that
[22:34:04] <prometheanfire>  same memory amount causing the issues more or less?
[22:34:05] <blueness> prometheanfire, i'll stabilize 3.8.12 later
[22:34:30] <klondike> l
[22:34:42] <klondike> prometheanfire: I'll tell after meeting don't wan to hijack this
[22:34:45] <prometheanfire> ok
[22:34:50] <prometheanfire> dome
[22:34:55] <prometheanfire> done
[22:35:41] <blueness> okay ... pax
[22:35:51] <blueness> so not exactly pax but pax related
[22:36:18] <blueness> the problem iwth xattr_pax boiled down to end-to-end support for retaining xattr values when emerging
[22:36:31] <blueness> this meant  a few pieces ahd to come together
[22:37:11] <blueness> 1) the qmerge phase, from $D to $ROOT has to retain xattr ... this was done by zmedico and arfrever a while back and USE=xattr portage has been doing that for a while
[22:37:55] <blueness> 2) we needed to support a special xattr namespace user.pax.flags on tmpfs, even for our gentoo-sources, because this way all gentoo users get end-to-end xattr unconditionally
[22:38:17] <blueness> its useless but harmless on vanilla systems, but if the users were to reboot into pax kernel ... breakage
[22:38:35] <blueness> 3) we needed coreutils' install to preserve our xattr namespace
[22:38:49] <blueness> upstream coreutils didn't really care ... the discussion generated no interest
[22:39:12] <blueness> also SwifT was worried about an unconditional --preserve which would preserve even selinux labels, this could be bad
[22:39:33] <blueness> os i gave up on that and write a protage wrapper for install, that's now in portage
[22:39:53] <blueness> i actually wrote it in bash first with assoc arrays, but that requires bash 4 and portage must be backwards compat to bash 3
[22:40:04] <blueness> so i rewrote the wrapper in python
[22:40:21] <blueness> its on the portage repo and will be release with the next release
[22:40:44] <blueness> at that point we'll have end-to-end xattr pax flag support and can reintroduce XT pax to the eclass
[22:41:31] <blueness> i don't know where we will go from there although vapier does like the pax specific patches on the toolchain, eg against glibc or binutils
[22:41:41] <blueness> but its way way to early to do anything drastic
[22:41:53] <blueness> <end-o-story>
[22:42:05] <blueness> i will now entertain questions/flames
[22:42:15] <klondike> blueness: hire an assasin and kill those oposing to the coreutils patches :P
[22:42:25] <blueness> klondike, in the end it is better
[22:42:31] <blueness> KISS = keep it simple
[22:42:38] <klondike> If a certain glibc dev is involved I'm willing to chip in ;)
[22:43:03] <klondike> blueness: more like you are hiding the complexity there
[22:43:17] <blueness> klondike, no it separates tools
[22:43:18] <klondike> inhouse builtins are known for being prone to issues
[22:43:19] <blueness> oh also
[22:43:34] <blueness> elfix,pypax-0.8.3 is stable
[22:43:43] <klondike> see the vulns I found on (e)udevs string handling functions
[22:44:01] <blueness> which means the paxmark.sh bash script is available for things that need pax markings at any point in the build system
[22:44:18] <Zorry> :)
[22:44:28] <blueness> klondike, i know but to keep me sane, i must follow systemd closely ... off topic
[22:45:01] <blueness> its too bad the hype around eudev obscures what i did there, i was able to eliminate over 300 unused symbols
[22:45:10] <blueness> and still follow upstream very closely
[22:45:15] <blueness> but i digress
[22:45:17] <blueness> next
[22:45:23] <Zorry> next
[22:45:30] <Zorry> 3.0 Selinux
[22:45:30] <klondike> blueness: this was nothing against eudev but udev :P
[22:45:40] <klondike> we have patched the vulns they introduced xD
[22:45:53] <Zorry> SwifT: ^^
[22:46:02] <SwifT> only one thing to say: 20130424 policies have been made stable a week or so ago as well as the userland. I just stabilized setools as well (with the swig1.3 dependency on it)
[22:46:25] <SwifT> that's it - working on an external project up to mid-july so little evolution in my projects otherwise :-(
[22:46:29] <pjschmitt> SwifT: I was wondering if we have had anyone trying sVirt
[22:46:39] <pjschmitt> I could work on that, and test the new policies
[22:46:52] <SwifT> i have bugreport on it, but don't know of anyone trying it to resolve it :p
[22:46:59] <pjschmitt> link me?
[22:47:06] <SwifT> will do
[22:47:10] <pjschmitt> I'd be willing to squash it
[22:47:17] <pjschmitt> could even do that on work's time :)
[22:47:55] <pjschmitt> I'll need to disable dontaudit so if you could help me sort through the false positives that would be great
[22:48:09] <SwifT> its bug 443630
[22:48:15] <willikins> SwifT: https://bugs.gentoo.org/443630 "SELinux + >app-emulation/libvirt-0.9.13-r1 - Segfault starting qemu domains."; Gentoo Linux, Applications; UNCO; gentoo:selinux
[22:48:35] <SwifT> will do, send me a mail and i'll get you on track
[22:48:41] <SwifT> that's it for selinux
[22:48:49] <Zorry> next then?
[22:49:03] <Zorry> 4.0 System Integrity
[22:49:20] <klondike> SwifT: ?
[22:49:21] <SwifT> yeah, nothing there sadly
[22:49:40] <SwifT> 3.10 still doesn't have my fix in it :(
[22:49:48] <klondike> No worries, live happens
[22:50:37] <SwifT> next
[22:50:39] <Zorry> next then?
[22:50:45] <klondike> yeah
[22:50:46] <prometheanfire> next
[22:50:52] <Zorry> 5.0 Profiles
[22:51:29] <Zorry> i don't have any thing on it
[22:51:44] <blueness> i added hardened/linux/musl/amd64
[22:51:50] <blueness> its just for testing
[22:51:57] <blueness> as i state above
[22:52:10] <blueness> remarkably hardened went perfectly fine on musl
[22:52:29] <blueness> so maybe another set of embedded hardend stages for the future
[22:52:44] <klondike> :)
[22:52:53] <klondike> More to build 64k demos on
[22:52:54] <blueness> oh i did remover all the experimental 13.0 stuff because it is now automagic
[22:53:09] <blueness> klondike, it is very different from both glibc and uclibc
[22:53:15] <blueness> we will see what its future is
[22:53:37] <blueness> i got some stuff in already mkostmp for eudev, so they are open
[22:53:52] <blueness> and dalias is eager to help with porting gentoo over
[22:54:00] <klondike> :)
[22:54:08] <blueness> but the biggest issue si that musl doesn't announce itself
[22:54:21] <blueness> so glibc announces itself and it multifarious versions
[22:54:28] <blueness> uclibc just announces itself
[22:54:40] <klondike> ahh publicity you mean?
[22:54:40] <blueness> and musl expects you to check the standard
[22:54:44] <blueness> no no
[22:54:47] <blueness> i mean like this ...
[22:54:58] <blueness> #if defined(__UCLIBC__)
[22:55:03] <blueness> then do uclibc-ish things
[22:55:05] <klondike> ahh I see
[22:55:05] <blueness> #endif
[22:55:12] <klondike> baha!
[22:55:13] <blueness> there is not __MUSL__
[22:55:25] <blueness> well they expect you do do things like __GNU_SOURCE
[22:55:32] <blueness> or __OPENX__
[22:55:33] <blueness> etc
[22:55:37] <klondike> should be doable anyways
[22:55:38] <blueness> or __POSIX__
[22:55:47] <blueness> its much much harder!
[22:55:56] <blueness> you have to actually know the standard
[22:56:03] <klondike> no
[22:56:04] <blueness> and the header stacking is very shallow
[22:56:24] <klondike> I mean you can add a -DMUSL in the CFLAGS
[22:56:36] <blueness> let's talk afterwards because now we're digressing
[22:56:40] <klondike> oki
[22:56:46] <blueness> but i mention it because hardened + musl go very very well
[22:57:03] <blueness> so we should port to it
[22:57:13] <blueness> next?
[22:57:15] <Zorry> next
[22:57:21] <klondike> next
[22:57:27] <Zorry> 6.0 Docs
[22:57:52] <klondike> nothing from me, busy with moving, and my swedish classes, sorry
[22:57:54] <SwifT> nothing here but to say that a3li does a great job on the wiki support, so y'all have to work with it :p
[22:58:23] <Zorry> SwifT:  did see stuff on the -dev ml list about it
[22:58:49] <SwifT> we'll be moving project sites to the wiki as well soon(ish) but I haven't fully read up on those threads yet
[22:58:49] <blueness> SwifT, is someone else porting my docs to the wiki
[22:58:58] <blueness> because ... i hate documenting ...
[22:59:01] <SwifT> if you're not doing it, no-one is ;)
[22:59:10] <blueness> i mean i like writing it but not formatting etc
[22:59:19] <SwifT> i can assist from august starting though
[22:59:29] <klondike> I think SwifT has a magic script
[22:59:32] <blueness> SwifT, is there some script?
[22:59:39] <blueness> well that' different
[22:59:43] <klondike> mediawiki is also easier than metadoc
[22:59:48] <blueness> agreed
[22:59:48] <SwifT> there's an xslt that you can use to get wiki-ish code, still requires some human reviewing on it
[23:00:03] <blueness> SwifT, i can live with that
[23:00:23] <SwifT> i was hoping to have it finished by now, but it'll have to wait a bit - i'm going to use it for moving lots of GDP docs to the wiki as well though
[23:00:36] <blueness> but honestly, if its a choice between hacking the ldso code in uclibc or formatting mediawiki, there's no choice, i'm a coding masochist
[23:00:40] <SwifT> now that the wiki also supports translations, there's nothing holding me back technology-wise
[23:00:47] <SwifT> hehe
[23:01:02] <SwifT> in a few months, you'll also be reading the gentoo-dev threads
[23:01:05] -*- blueness cyberhugs SwifT 
[23:01:32] <SwifT> welcome to the politics
[23:01:33] <SwifT> :p
[23:01:35] <blueness> guys what a complementary team we are!
[23:01:38] <klondike> blueness: come to fosdem, do it for real :P
[23:02:08] <prometheanfire> if I go to hong kong I expect to see each and every one of you :P
[23:02:12] <blueness> okay i'll do my part in migrating my docs, i'll wait for your script and pointers
[23:03:06] <klondike> next?
[23:03:10] <blueness> NEXT!
[23:03:20] <Zorry> 7.0 Bugs
[23:03:33] <Zorry> any thing?
[23:03:54] <klondike> let's retake ffmpeg and stackcheck here
[23:04:14] <klondike> blueness: if I convince upstream will downstream preemptively apply the patch?
[23:04:24] <SwifT> i'll be leaving now, my eye-lids are already resting on my knees :p
[23:04:32] <klondike> night SwifT
[23:04:35] <Zorry> klondike: most likly
[23:04:52] <Zorry> if it get commited to the code
[23:04:57] <klondike> oki I'll try to focus a little bit more my efforts on that then
[23:04:58] <pjschmitt> SwifT: I do have one thing before you go if you're here
[23:05:25] <pjschmitt> I was thinking, do you guys think it would be a good idea to make gnome and kde profiles for hardened, and selinux gnome and kde profiles?
[23:05:57] <klondike> pjschmitt: nah, too much bifurcation
[23:06:00] <pjschmitt> I can see a few use cases when a user may want to use selinux targeted to contain firefox
[23:07:18] <blueness> klondike, go for it
[23:09:23] <klondike> I will
[23:09:24] <Zorry> pjschmitt: we did have before but not enable in  the profiles
[23:10:04] <Zorry> pjschmitt: we are trying to keep the profiles minimal
[23:10:13] <Zorry> next?
[23:10:33] <Zorry> 8.0 Media
[23:10:42] <klondike> Little to say
[23:10:46] <klondike> Meeting twitted
[23:10:57] <klondike> no oncoming talks on my side
[23:11:05] <klondike> Anything from you guys?
[23:11:34] <prometheanfire> not really, spotify is anoying but that's it
[23:11:39] <klondike> LOL
[23:11:59] <blueness> nothing
[23:12:04] <klondike> prometheanfire: did you read the article I gave you?
[23:12:08] <prometheanfire> yes
[23:12:45] <klondike> you should be able to modify the paths yourself
[23:12:50] <klondike> anyways, next?
[23:14:00] <klondike> Zorry: ^^^
[23:14:13] <blueness> is there a next?
[23:14:20] <Zorry> 9.0 Open floor