[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
