[01:56:17] Skimming the diff of pax-only patch in strcat's repo branch makes me think porting this is somewhat nightmarish since we're going to need to evaluate all that asm. Probably need to think about automated testing infrastructure both in terms of builders and fuzzers + reporters [01:57:09] a lot isn't going to be wanted [01:57:18] I am actually in the process of building something quite similar, also having to deal with kernel code at work... [01:57:22] the main thing are RAP asm changes [01:58:01] I've definitely not delved deep enough to understand what those contexts are going, so far my reasoning goes as far as inference based on function names and where i'm seeing them come up [01:58:58] which asm [01:59:30] Right now i'm trying to work out the overflow protection stuff [01:59:45] that isn't in scope it's being dealt with already [01:59:55] if you mean REFCOUNT [02:00:21] yes [02:00:30] yeah, don't worry about that [02:00:47] the main asm changes that matter are to make the asm RAP compatible [02:01:06] Actually trying to just get a sense of scope and basic functions, trying to let my brain hook whatever knowledge is rolling around in there to get better understanding. [02:01:13] and a lot of that could be figured out from historical diffs between patches when it got introduced [02:01:42] RageLtMan: 50%+ of the stuff in the patch isn't in scope [02:01:53] The paxteam letter from a couple of days ago seemed to mention that current efforts at reference counting had some sort of flaw, one sec, lemme see if i can find it. So i'm hoping to understand what the difference are long as i'm looking at it [02:02:02] ah [02:02:16] RAP is out of scope, or other functionality from pax? [02:02:21] no, I didn't say that [02:02:32] or just the implementation? [02:02:34] legacy functionality isn't in scope, stuff already happening upstream and likely to land isn't in scope [02:03:51] the faster (than upstream) current REFCOUNT implementation in PaX will likely land upstream [02:04:01] there's no reason to extract that separately from the existing work [02:04:28] once it lands, approaching it as opt-out instead of opt-in like PaX can be done with the same infrastructure [02:04:39] or just waiting [02:05:01] not all the atomic_t that can be overflow checked are reference counts though, although it'd be a weird thing to focus on [02:06:59] strcat: in terms to trying to get a sense of the efforts - i'm currently looking at kees' repos (https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/) and yours as the indicators of activity. any place i should add to my scope for upstream/adjacent changes? [02:08:27] regarding refcount, my understanding is that refcount_t is replacing most atomic_t because they're used as counters, while grsec/pax did the opposite and set the ones not used as counters to something else [02:09:00] and I'm saying it isn't in scope because it is being worked on and it needs to be seen what lands upstream to build on that [02:09:43] REFCOUNT is being worked on, it isn't something to worry about yet [02:09:56] gotcha. talk about multidimensional planning... How do you determine which pieces are isolated enough to work on such as to avoid collision? [02:10:32] it doesn't have to do with 'collision' really [02:10:36] it is just already being worked on [02:10:46] Roger. [02:11:18] the high priority is RAP and KERNEXEC page table protections, nothing else is a high priority, since all of the wanted stuff is pretty straightforward (don't mean that it's not a lot of work, but that it's not complex work) [02:11:27] all of the other wanted stuff* [02:11:27] *** Quits: _andyj_ (uid24906@gateway/web/irccloud.com/x-ahfkkujswkmghilx) (Quit: Connection closed for inactivity) [02:11:41] How does that apply to ASLR? In that letter, paxteam indicated their aslr method not only provides significantly more entropy (though IMO thats a bit of a red herring, its generally infoleaks that kill it), but more importantly avoid memory fragmentation issues. [02:12:21] I didn't mention ASLR [02:12:25] ASLR isn't complex code though [02:12:51] Hence my question - again, trying to wrap head around the scopes and angles this is all dealing with. [02:13:08] you're bringing up a bunch of unrelated stuff [02:13:33] the focus shouldn't be on trivial stuff like changing the ASLR implementation to be at least as good as PaX, it should be on the complex features that are going to bitrot the most [02:13:53] my expectation is that I won't be doing that alone [02:14:02] *** Joins: syrex (~master@v22016063647935336.nicesrv.de) [02:14:46] Based on the increasing number of people in this chan, and who some of them are from prior interactions, i'd say you're gathering the right kind of interest. [02:15:01] this is more work for me than just maintaining the CopperheadOS kernels, and I'm doing it with the expectation that it's a collaborative project where the time I'm putting in will be dwarfed by the time other people are putting in [02:15:27] okay, but work needs to start, the longer it takes to start, the harder it gets [02:15:40] the last test patch is 4.9, the current kernel is 4.11, and soon enough 4.12 will be out, etc. [02:16:03] the longer it takes for people to decide to start working, the more work and frustration will be involved [02:16:14] Its not feasible for a single person. Things like this need community drivers of some sort - the issues section in GH is a good start, maybe getting people to self-assign here or on github could be a worthwhile effort [02:16:51] it's a theoretical problem until there are people doing the work [02:17:00] Hitting the kernel mailing lists may get people moving too... your argument for "time lost is code lost" is totally valid [02:17:07] once people start seriously working on it, it can be organized more formally [02:17:12] until then, there's nothing to organize [02:17:41] priorities == RAP and KERNEXEC page table prot, but there's a list of other stuff on the issue tracker [02:17:59] You need people capable of doing the work too... my C skills are a bit short of this (not to say i'm not getting spun up, but i'm a long way off from where you are) [02:17:59] but most things other than those priorities isn't really solving the main issue [02:18:58] if only C knowledge was needed it would be easy [02:19:02] I'll try to pass the good word around, while i myself may not be able to execute this at a level of quality which would let me sleep at night, maybe some of my colleagues who can do it can spare cycles to implement. [02:19:23] There's hardware specific concern as well... [02:20:07] all that's required are capable people willing to dedicate time, there's nothing particularly arcane / magical about this stuff [02:20:33] since those parts are almost all being ignored anyway [02:22:54] Disambiguating the magic from the functional stuff takes a bit of time for the uninitiated. Any way you could mark the red herrings for us newbs? :) [02:23:50] I filed issues in the tracker about features that are wanted, that's done [02:24:00] if there's something else that should be implemented, it can be filed there [02:24:29] the goal is not extracting 100% of the code and moving it over, and breaking it down into components and deciding which ones to take [02:24:46] at least 50%+ is definitely not in scope [02:24:50] I meant more along the lines of "pointers for newbs about whats relevant in the provided patches implementing those features" or if easier "pointers for what to ignore in the public patch" [02:25:14] no, I can't do that [02:25:17] other people can do work [02:26:03] this won't go anywhere if I need to keep taking on more [02:26:24] if people want something, they can do it, regardless of what it is [02:26:47] as I said, by simply maintaining/managing this and doing the forward porting, that's already a lot of my time, and it's invested under the assumption that there are significant contributions made by other people [02:31:12] based on the issue tracker and what i'm reading so far, the kernexec and pax_open_kernel/close thing may be within my grasp [02:31:54] only the page table part is in scope atm [02:32:21] so the baseline functions and page table usage, not the other usage of them with __read_only, because that needs to be adjusted to be upstreamed, and the API will probably be different [02:32:31] you should subscribe to kernel-hardening and follow it [02:32:48] sorry, missed that there even was a list [02:37:53] the openwall list, correct? [02:37:59] yes [02:38:05] done. thanks for the heads up. [02:38:09] follow the list, and read the archives maybe [02:38:11] recent ones at least [02:38:15] better than asking me ;p [02:41:12] You should have gone into medicine... you'd have made a killer corpsman with that cheery bedside manner ;-). In all seriousness though, thank you for taking the time - hopefully we can repay that effort with commits and improvements as we go. [02:42:24] my frustration is that people ask lots of questions, and I try to be helpful, but then there's rarely if ever follow through where work gets done, and my effort trying to do that far outweighs the benefits [02:43:46] I've spend 2.5 years working on a project where it was assumed people would contribute, and it didn't happen, and lots of time was spent trying to make it happen, so I won't me making that mistake in the future - and it is a mistake, because I don't even know that I'm spending my time on the people likely to contribute [02:43:56] so here: change of plan [02:44:03] after someone starts contributing, I will help them [02:48:37] Thats not a bad idea, though should probably be presented in the GH readme - a la "start work on PRs in public, get collaboration, and receive advice from people with heads far less up their ass than you." People only PR-ing things when they believe them to be done is not going to work here. [02:51:35] I get your frustration on the contributor thing, spent countless hours teaching god knows how many people intimate details of things only to have them get confused, throw their hands up because theyre in a rush, and give up. Its abysmally infuriating. The occasional one who sticks and keeps learning is quite often worth the 20 missed ones. Getting one of the tech big-boys to speak in a public way about this would be a huge help too... in case anyo [02:51:36] ne here is in a position to nudge them in that direction. [02:52:19] it's rarely that people got confused it's that they never tried to put serious time into it, beyond asking questions, etc. [02:52:47] not everything is like this, in fact what I'm talking about mostly isn't [02:53:53] if people aren't actually going to follow through on contributing to high-level, application-layer java code, I don't think the chances are going to be better for low-level platform specific C code [02:54:34] Well, in my personal case, the next week is buildbots and packaging for our own DKMS pieces and userspace, but i should at least be able to put in some actual hours toward end of week to try and figure out which of your prioritized issues i can tackle (if any) [02:55:20] Sorry, not tracking - Java? [02:55:25] nvm [02:56:03] Take a look at openzfs as an example of weird kernel code which gets tons of contribution. its doable, it requires a community to build the momentum [02:56:50] intel and a number of other vendors are pushing to the linux branch, with a ton of that getting upstreamed through a complex process into other OS'. lots of turning gears and lots of people, but its doable [02:59:14] all I'm going to do is facilitate there being an updated tree to do work for, not doing it all or doing mentoring/outreach [02:59:25] as always, someone can step up and do what they think is important [03:03:20] To think, users believe there are thousands of people like you who are well paid by their companies to do this. Governments and companies apparently have no interest in funding a secure execution context - that letter paxteam wrote indicates theyve never even been approached to upstream. The politics of that debate are well over my head, but from what little i do get, it has something to do with Linux maintainers not wanting to alter core componen [03:03:20] ts for the sake of security, and dependent users (companies) not wanting to pay anyone (hence the closing of the sources in the first place). [03:38:16] *** Joins: catpigger (~catpig@p54A57AFB.dip0.t-ipconnect.de) [03:41:55] *** Quits: catpig (~catpig@p54A5789E.dip0.t-ipconnect.de) (Ping timeout: 255 seconds) [03:42:12] RageLtMan: as far as "help for noobs" I definitely would put myself in the category of noob. Hop on the mailing lists, pick a feature from grsec and start grep'ing through a grsec patched kernel and try to understand how it works. [03:43:20] but I would like to provide some basics to getting started in the form of a blog post or something. [03:44:12] nmatt: please! Blog posts, wiki entries, issues, anything to help bootstrap newcomers. Need to think like pushers - get people hooked somehow [03:46:43] will do. also I'm almost done revamping the wiki conversion [03:47:36] I would love to find a way to amicably engage the grsec people - they're working on their next-gen stuff, probably wouldn't mind not having to maintain forward porting of a bunch of this stuff if they were properly compensated to help upstream it. If i'm reading the paxteam letter correctly, they basically left the door open to someone making them a realistic offer to do the work (at least thats how i understand the section regarding upstreaming e [03:47:36] fforts) [03:48:23] *sigh* and silicone valley is investing hundreds of millions into trendy juicers, while infosec efforts are basically penalized. [03:48:58] if you think they want compensation to get it upstreamed, you're misunderstanding spender [03:49:20] spender doesn't want money, fame or a lower maintenance burden [03:49:39] I have no idea what he wants, but it's definitely not that [03:50:46] again, politics a bit over my head, but paxteam is a separate person/people, right? [03:51:04] yes and extremely loyal to spender [03:51:06] they work together I think [03:51:17] they are 2 people but they aren't separate entities in terms of getting one to do something the other doesn't want to do... [03:51:23] they make decisions together [03:51:40] I wouldnt suggest trying to separate them, simply that the tone of response seems different, i cant speak to content - havent seen much from spender on all this [03:52:58] http://www.openwall.com/lists/kernel-hardening/2017/05/11/2 [03:53:12] pax team shares the same tone [03:53:16] RageLtMan: https://github.com/thestinger/linux-hardened/commit/2929f2d18b3a1f73f8d161c5886f7b5ee01455d3#commitcomment-22134970 [03:53:21] good luck cooperating with spender [03:53:58] I'm accused of 'plagiarism' for stumbling on this bug when I added the leading 0 byte to the canaries, which I only did because I implemented heap canaries and it was related [03:54:46] meanwhile, the earliest public mailing list post from 2007 about it that *he links to* does not mention PaX [03:55:05] the patches he's saying fixed it earlier are not even publicly available [03:55:29] how the hell am I supposed to know that they fixed the bug in jan 2007? the earliest pax patch I see is august [03:55:32] huh, i'd have thought theyd be supporting coppherhead full-on [03:55:43] earliest public mention is june, which is earlier [03:55:53] RageLtMan: uh, no, spender has never supported us even when we were on good terms [03:55:58] we could never find a way to work with him [03:56:22] I asked if he'd accept a full time job working on grsec where he got paid well and still had full control [03:56:24] he said no [03:56:31] so tell me, what does he want? [03:57:00] he didn't want to work with us, he didn't want us to get him a full time job working on grsec, he didn't want to work with citizen lab [03:57:08] anything involving money he hasn't been interested in [03:57:24] and then earlier, when I asked about funding certain work, he implied that there wasn't time to do it all unless there was enough money for full time work [03:57:31] but then he was unwilling to do full time work for 1 company [03:57:46] Wasn't he w/ accuvant till they were bought out? [03:57:48] it needs to be something like the linux foundation with say 10+ different companies pooling money or he won't do it [03:57:51] RageLtMan: that isn't grsec [03:58:00] sure he is not unemployed [03:58:07] his full time job is not grsec, and never has been [03:58:32] anyway, there is no working with spender, there is only purchasing their products, and they don't seem very interested in actually selling them [03:58:47] try having your company get a commercial grsec license atm [03:58:48] infosec research i imagine given the leanings... if not straight up red team practice [03:58:58] seriously, try [03:59:06] have your company contact grsec sales [03:59:19] i'm trying to get a private one - this mess screwed us BAD. we just got people to start TRYING grsec kernels in builds for upcoming projects [03:59:22] for 1) the patches, 2) RAP (which is more hilarious) [03:59:29] RageLtMan: ok, so you'll see [03:59:36] have you contacted them yet? [03:59:49] yeah, but what they're suggesting doesnt quite work for us [03:59:58] after you contact them, you'll understand [04:00:01] especially if you ask about RAP [04:00:01] we actually dont need the stable as much as the test because we're working on systems a year or two out [04:00:12] how much for RAP? [04:00:56] more than I earn in a year [04:00:58] ironically for this hospital project we cant use RAP - cluster of GPU compute boxes with docker containers from nvidia using their proprietary driver, so in our internal testbeds we build without it. We use RAP on our virtual images in our private cloud and on the control/compute nodes [04:01:19] lol [04:01:33] jduck: do you remember how expensive RAP was [04:01:33] the problem i have now i that even if i do get a set of patches to work with, i wont be able to test them on the hospital's systems until THEY buy a license, without having been able to test it [04:01:35] its a nightmare [04:01:37] jduck: it's probably more now tho [04:02:10] nmatt: 85k USD / year [04:02:20] nmatt: and I think you get 2 support questions a year, or something like that [04:02:37] isn't that generous of them [04:02:46] thats literally a rounding error for companies running medical devices with exposed interfaces or other critical infrastructure. [04:02:48] and they haven't sold it to anyone yet afaik [04:02:54] I don't think they want to [04:03:07] seriously I almost believe that they'll just raise the price high enough that they think you won't pay [04:03:12] I don't really think so [04:03:26] but I wouldn't be surprised if it cost a lot more than 85k/year if it was a bigger company asking [04:03:34] it's only for a small company that 85k/year has been offered [04:03:46] (companies totally unable to pay that...) [04:03:46] whats a compromise cost when you lose PHI on a large scale? the stock price hit alone is more than any RAP license [04:04:27] is there even a licensing model around what you guys do? you wouldn't be able to distribute the devices, right? [04:04:48] RageLtMan: there is no point of us licensing stuff from them for CopperheadOS for multiple reasons [04:05:00] it wasn't us that tried [04:06:10] anyway, I don't like spender much anymore, he's been a dick to me since before any of these recent events [04:06:21] With my pro-services hat on, my take is "evaluate options, determine best of breed within operating constraints, implement/recommend." This mess has created constraints i dont even fully grasp yet, but theyre mostly in the business logic and result in a massive decrease in security posture. [04:06:51] he liked me before Copperhead, but after that he said bad things about me to a journalist behind my back - while I was still going out of my way to support them, and I still did after, I just shrugged and moved on from that [04:07:01] anyway [04:07:08] no one else is allowed to work on anything [04:07:09] I sort of got the sense that industry sees the guy as a dick who's right. [04:07:19] he's often right [04:07:21] not always [04:07:23] similar to linus [04:09:30] The ripple effects of all of this will haunt us for the next decade. If this project takes off, it will help more people than grsec for the simple fact of being built-in, if it dies on the vine, literally everyone on the planet will be paying in one way or another. [04:10:45] I cant see a lot of these companies who have to be forcibly pushed into thinking about security by a red team guy slapping them with their clear text passwords in a leather-bound tome taking the effort to work out licensing with all the constraints and uncertainty - they'll see it as a large business risk. [04:19:01] I thought this was supposed to the be channel free of this endless bitching strcat =p [04:19:31] yrp: yeah well spender is actively bothering me [04:19:38] yrp: and it wasn't me that said that ;p [04:20:20] 20:21 is there somewhere I can go where people talk about the technical components of grsec/kernel security? i just dont care about if its open or not. [04:20:22] 20:21 yrp: freenode ##linux-hardened [04:20:24] =p [04:21:33] I think it's worth noting anything technical offered by spender and to ignore everything else. the politics are tiring at this point. [04:22:04] *** Quits: blueness (~blueness@gentoo/developer/blueness) (Quit: blueness) [04:22:30] kees: yeah but he's willing to make statements that are technically accurate but very misleading [04:22:41] sometimes *barely* technically accurate [04:22:52] right [04:23:08] like saying X upstream is 'broken' but not wanting to say why, and then it turns out to me something you already knew and that isn't compelling [04:23:14] like saying VMAP_STACK is broken / insecure [04:23:29] I mean, that's basically how he and I first met. he flamed me on my blog about emulated NX technicalities. :P [04:23:40] right [04:24:01] yrp: well https://github.com/thestinger/linux-hardened/commit/2929f2d18b3a1f73f8d161c5886f7b5ee01455d3#commitcomment-22134970 [04:24:11] yrp: https://github.com/thestinger/linux-hardened/commit/09262ec80091c27c21171c7e90e30c1de9e38b3a#commitcomment-22134962 [04:24:17] it's on my repo, not somewhere else [04:24:19] ;\ [04:24:31] i dont care [04:24:42] like, fine if you guys are going to bitch about it here too whatever [04:25:07] it's spender coming to my repo and whining about nonsensical stuff, lets me clear about that [04:25:12] s/me/be/ [04:25:38] 'in more complete form' [04:25:49] is there -another- channel where people interested in kernel security hang out where its not endelss bickering about who said what mean or misleading thing? [04:25:57] he's going to be a reality in this project, so it's best to figure out how to manage his interjections appropriately. it may even end up becoming a FAQ entry on the wiki [04:26:22] yrp: spender will find it and try to ruin it too, so let's stay here and just ignore it. [04:26:26] kees: not necessarily I could move the repo to copperhead and just ban him ;p [04:26:29] orgs can ban people [04:26:38] I just dont give a fuck if spender is an asshole. Linus is a famous asshole, and people seem to work with him just fine. [04:27:01] they both drive people away. :( but for those that put up with it, it's ignorable. [04:27:08] strcat: yeah, if it comes to that. [04:27:44] *** Quits: somis (~somis@149.56.153.184) (Quit: WeeChat 1.7.1) [04:27:56] yrp: linus is not really an 'asshole' though, he likes flame wars / bickering and is a bit rude - I've never seen him really be a dick to someone, beyond flaming them and I doubt he does that irl [04:28:20] and he sticks a lot more to technical criticism even when he's rude about it [04:29:26] he's not going to send me an email saying I'm a worthless, unintelligent waste of space with 0 integrity because I didn't swear at kees for him, which is probably something he'd like just like spender [04:30:44] worth noting I was on good terms with spender to the point that he'd tell me stuff that wasn't public in PMs until very, very recently [04:32:03] Cool. So if anyone else here knows cool spots where peopel discuss kernel security shit and isnt a dystopian version of high school where everyone has worse social skills somehow, please hit me up. [04:32:48] *** Joins: blueness (~blueness@gentoo/developer/blueness) [04:33:37] kees: https://github.com/thestinger/linux-hardened/commit/e6c5ea972e1188eeb3a43b03d338e2a7b3a37fc1.patch [04:33:40] kees: the new version btw [04:33:48] kees: covers strlcpy and has the compile-time errors split [04:34:08] just haven't heavily stared at it and tested it yet [04:37:29] strcat: awesome, thanks! [04:41:36] strcat: ooh, I love the strlen coverage :) [04:42:39] kees: yeah and easy to reuse it, strncat uses both strlen/strnlen and relies on those existing checks [04:43:08] kees: it might be possible to do string compile-time checks but it's kinda annoying and might not find anything [04:43:16] need to do __builtin_constant_p(__builtin_strlen(s)) maybe [04:43:20] then use __builtin_strlen(s) [04:43:53] anyway not super important, since anything caught at compile-time will be caught when the code actually runs if there isn't a compile-time check [04:43:57] it's just nice for productivity [04:44:35] it'd have been annoying to find those memcpy instead of strncpy cases slowly over time, for example [04:44:44] but I'm sure there's other stuff like that not caught at compile-time ;p [05:07:14] I only worry about runtime false positives. :( [05:08:30] kees: that's mostly from using __builtin_object_size(p, 1) though, I don't think this should catch anything that's not undefined [05:09:01] kees: this is all __builtin_object_size(p, 0) for now, so no intra-object checks, which is where false positives come from [05:09:15] there can be a FORTIFY_SOURCE_STRICT later [05:10:11] I'm not 100% clear on which stuff is actually a false positive with the stricter mode vs. genuinely undefined, so not going to propose that until I can actually explain it properly (which glibc, etc. don't seem to do they just say _FORTIFY_SOURCE=2 'can' cause false positives while _FORTIFY_SOURCE=1 shouldn't) [05:14:29] *** Joins: warsh (~warsh@unaffiliated/warsh) [05:17:55] *** Joins: kerframil (kerframil@gentoo/user/kerframil) [05:23:17] wiki now looks better: https://github.com/thestinger/linux-hardened/wiki [05:25:37] strcat: let me know what you want changed on the wiki in order to make it "official" [05:26:08] nmatt: it might be fine now, /r/linux was just being irritating and I shooed them away [05:26:23] cool [05:27:10] nmatt: https://www.reddit.com/r/linux/comments/6ag9nd/the_hardened_kernel_project_is_working_on_getting/dhecyo9/ [05:27:51] oh wow... didn't see that [05:28:26] nmatt: https://www.reddit.com/r/linux/comments/6ag9nd/the_hardened_kernel_project_is_working_on_getting/dhfahc3/ and more nonsense [05:28:27] cause /r/linux [05:28:34] nmatt: that's when I added that, to shoo them away [05:29:19] yeah and we don't have that bit about stability anymore [05:30:38] *** Quits: citypw (~citypw@207.226.142.235) (Quit: Leaving) [05:32:30] kees: I could switch it to BUG [05:32:54] kees: it ended up like this b/c BUG can't be used in that header [05:33:23] could rename fortify_panic -> fortify_error and print error + BUG or w/e [05:43:23] *** Joins: N8Lord (~n8fear@p5DD14A0F.dip0.t-ipconnect.de) [05:46:06] strcat: the nice thing about BUG is that it isn't strictly a panic. [05:46:36] *** Quits: n8fear_ (~n8fear@p57923D26.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) [05:46:44] kees: yeah and I'm fine with using BUG, I'll do it for the next version [05:46:51] kees: but it needs a fortify error symbol [05:47:11] also BUG prob isn't available in some of that early code [05:47:23] (in addition to the wonderful cyclical header dep thing that'd happen ;p) [05:47:31] can just replace the panic with it [05:55:45] strcat: on the bright side, spender's doing free code review ;) [05:56:01] no, he's not [05:56:14] if he finds a problem, he won't say so, he'll give you a hash [05:56:25] if he makes an actual statement, it's because it's not helpful [05:56:47] and he's being deliberately misleading in his statements there so I don't really see how that's code review [05:58:18] Was hoping it was along the lines of "gruff but informative" - only saw the two comments you showed. Does GH have a good way just to show comments on a repo's commits? [05:59:26] no, it's unhelpful, unproductive, misleading claims [05:59:28] not code review [05:59:46] RageLtMan: no [05:59:54] I linked everything he posted [06:01:04] Since the start of this mess i've seen lots of references to terms like misleading, lies, etc. For those of us not deeply familiar with the semantics and history around all of this, its pretty much impossible to disambiguate without hundreds of hours of commit review [06:01:32] i've no idea whats what at this point :). Seems to be the theme of 2017 [06:01:56] so then look at what I linked [06:02:14] Discussions seem to focus on who implemented what and when across a number of articles, mailing lists, etc, but i'm not sure what any of that has to do with the how aspect of the kernel as it stands today (4.9+ lets say) [06:02:17] there's nothing subjective or ambiguous about it [06:02:42] It seems he's pointing out that he has already done this, which is great, but now that its not public, its sort of a moot point. [06:03:12] RageLtMan: he hasn't done it [06:03:22] he did something similar, but different, that was never included in the grsecurity patches [06:03:40] Making it all the more confusing why its brought up. [06:03:47] and he makes an untrue claim that what he did is broader / covers more, based on being manipulative about me not including alloc_size in the same commit [06:03:50] RageLtMan: there is nothing confusing [06:03:54] you can see my code, you can see his code [06:03:58] far as i understand what you're doing, is you're pushing pieces of the hardening stack from copperhead up [06:04:27] in this case the gcc fortification relevant pieces [06:05:04] it's improved upon since the initial implementation in CopperheadOS, and either way it's not the same as any previous implementation [06:05:16] which, if you read the commit message, look at the code, and look at what he linked, is obvious [06:05:22] there is nothing subjective there [06:05:27] that part im seeing - the differences [06:06:27] in fact it explains in the commit message how it's different than the glibc approach, and it's easy to see that the linked code is the glibc approach (chk functions, not inline, only checking for write overflows, not reads - and not covering as much of these) [06:06:56] so, lets not pretend this is a matter of opinion, I'm not going to tolerate that [06:07:12] it's spender unjustifiably being a manipulative dick, there is no technical value to what he said [06:07:18] their implementation seems very different, you're covering strings here [06:07:50] whats the purpose of that behavior? I guess i'm having trouble understanding why someone would go through that trouble [06:08:18] because he's been incredibly pissed off at me for mentioning that useroffset/usersize were added as new features to PaX USERCOPY in the public patches [06:08:35] that's why he banned me, that's why he repeatedly antagonizes me in both public / private now [06:09:55] define public patches in this context - you mean added by someone outside the team and pulled back in by them, or things they added only to the public patches for some reason? [06:10:30] I'll restate what I said [06:10:51] I posted to a kernel thread mentioning that a PaX feature existed, that is part of the public PaX and grsecurity patches [06:11:08] spender considered that to be "leaking" information to 'evil' upstream [06:11:17] information that anyone can see by looking in the patch [06:11:20] so I was banned for it [06:11:25] I can give you his own words, if you want that [06:12:08] all set, got the context. still confused as hell, but understand what transpired [06:12:17] 2017-05-11 19:20:39 strcat I do argue your side of things sometimes but I'm not going to spend all my time doing that [06:12:19] 2017-05-11 19:21:02 strcat the mailing list thread you banned me for mostly involved criticizing them [06:12:21] 2017-05-11 19:21:28 spender nah you leaked stuff [06:12:23] 2017-05-11 19:21:34 strcat 'leaked' [06:12:25] 2017-05-11 19:21:36 strcat it's in a public patch [06:12:33] im starting to think i understand linux culture far less than its mechanisms [06:12:34] 2017-05-11 19:23:59 spender was talking about you leaking a bunch of stuff they hadn't noticed [06:12:36] 2017-05-11 19:24:09 spender like, there was no reason for it [06:12:38] 2017-05-11 19:24:23 spender aka it was contributing to their plagiarism [06:13:05] well, you keep making it seem like there are 2 reasonable sides to this and making me dump more explanations / info here vs. doing something useful [06:13:33] i appreciate you filling me in, just seems like madness all around. how is there plagiarism in a gplv2 project? [06:13:55] he considers it plagiarism / stealing to take code from grsecurity, and upstream it, even if you give full credit about where it came from [06:14:05] use without attribution? It all sounds weird in the GPL world. [06:14:12] use *with* attrition [06:14:14] oh. [06:14:15] attribution [06:14:23] and if you give credit, he considers that abusing the brand / reputation of his project to peddle inferior stuff [06:15:00] so, most people have given credit, so he's mad about 1) plagiarism (despite there being credit, and it being GPL2), 2) abusing his brand to promote their stuff, by saying "based on work in grsecurity" in the commit msg [06:15:13] is that because some embedded vendor ripped them off, or does this thought process predate that? There's also the "what happens to grsec and its benefits if spender is hit by a bus?" concern [06:15:30] he wasn't unreasonable as hell like this in the past, it's a recent thing [06:15:43] he was never like this 2+ years ago [06:15:58] in fact he tried to convince upstream to implement the stuff in grsecurity [06:16:07] engineers burn out every once in a while... they tend to get pretty angry during those periods [06:16:18] doesn't have to do with that [06:16:31] some companies did unethical stuff, and he projects that onto anyone working on upstream code now [06:16:36] guilt by association [06:17:16] from what i recall of the original post about the stable series, they tried to defend their trademark and were told to go screw by the courts. maybe he feels the system failed them [06:17:23] that has nothing to do with me [06:17:47] or other people deriving changes to submit upstream from his GPL2 code and giving full credit to him [06:18:03] not saying it does, or kees, or anyone else. just trying to piece together whats going on, the players, and motivations. that last part is eluding me completely. [06:19:04] That commit for the string functions is quite educational, thanks :) [06:21:39] so basically consumers which for some reason do bad things with strings can still explicitly call out the unsafe functions, but it will require developers change their code to do this and are at least aware of the error [06:22:28] the compiler tries to detect buffer sizes for both src/dst buffers and inserts runtime checks to detect overflows, along with giving compile-time errors when the size is constant [06:24:03] so if you do 'char buf[40]; strcpy(buf, s);' it will essentially replace that with 'char buf[40]; if (strscpy(buf, s, 40) < 0) abort();', etc. [06:24:42] it covers the mem* functions in string.h and most of the str* functions, both reads and writes [06:26:54] it's a small feature, but it finds / mitigates a decent number of bugs, so it's useful, and it was a good way to start on upstreaming stuff [06:30:02] small and very cheap performance-wise [06:31:18] there are already a dozen little bugs fixed because I decided to work on it, and it didn't take much time to make, but really, there is tons of more important stuff to work on it and I don't want to focus on that just because someone is being an idiot about it [06:37:26] thank you, both for the work and explanation :) [06:38:32] ive been keeping our own arch packaging for kernel with grsec stuff, updated it to use the unofficial 4.9 patches and the only thing which broke was the need to add a hook to update grub for the missing grsec string. good god i love Arch packaging [06:41:57] havent decided yet what the hell i'm to do about our own stable repo... so far this is only in testing, but eventually im going to have make a call on whether to try and compose things from hardened and kspp or try to move forward on minipli's stuff if i can't work something out with grsec for licensing. [06:42:26] i wonder what the alpine people are doing... [06:46:08] as a complete aside, i have a technical question: i've observed situations where unsafe memory operations in kernel modules of KVM instances are apparently caught by the hypervisor's grsec kernel. usercopy issue with an skb from netfilter. we never caught the bug until i ran a vm on a grsec patched host. It didnt log to dmesg on the host, but consistently crashed the kernel module in the VM, only on grsec hosts... how is this possible? I was under [06:46:08] the impression that KVM didnt paravirt operations outside of IO [06:59:01] *** Quits: White_Light (~Spacemen_@cpe-108-167-11-28.neb.res.rr.com) (Quit: Leaving) [07:05:04] *** Joins: White_Light (~Spacemen_@cpe-108-167-11-28.neb.res.rr.com) [07:11:07] https://github.com/thestinger/linux-hardened/issues?q=is%3Aopen+is%3Aissue [07:11:10] there all labelled [07:11:25] need to figure out rest of stuff that's considered in-scope now [07:16:28] thank you strcat [07:16:37] btw, regarding the alpine piece: (47/56) Installing linux-hardened (4.9.27-r1) [07:16:57] looks like they changed the name too, and by that version number i'm assuming the minipli patches [07:23:20] *** Quits: polyzen (~dmc@unaffiliated/polyzen) (Remote host closed the connection) [07:25:31] *** Joins: dmc (~dmc@unaffiliated/polyzen) [07:25:38] *** Quits: dmc (~dmc@unaffiliated/polyzen) (Remote host closed the connection) [07:27:48] *** Joins: dmc (~dmc@unaffiliated/polyzen) [07:49:22] *** Quits: catpigger (~catpig@p54A57AFB.dip0.t-ipconnect.de) (Quit: Leaving) [08:02:35] *** Quits: kerframil (kerframil@gentoo/user/kerframil) (Quit: Leaving) [09:22:20] *** Quits: strcat (~strcat@archlinux/trusteduser/thestinger) (Quit: WeeChat 1.7.1) [09:59:44] *** Quits: N8Lord (~n8fear@p5DD14A0F.dip0.t-ipconnect.de) (Quit: WeeChat 1.7.1) [10:29:14] *** Joins: b0untea (~b0untea@LStLambert-657-1-110-45.w92-154.abo.wanadoo.fr) [10:37:56] *** Quits: dave0x6d (uid190567@gateway/web/irccloud.com/x-gguacgqtiweapebb) (Quit: Connection closed for inactivity) [11:54:37] *** Quits: blueness (~blueness@gentoo/developer/blueness) (Quit: blueness) [13:17:01] *** Joins: blueness (~blueness@gentoo/developer/blueness) [13:30:13] *** Quits: blueness (~blueness@gentoo/developer/blueness) (Quit: blueness) [13:47:59] *** Joins: aissen (~aissen@unaffiliated/aissen) [13:48:06] yeah :-) [15:15:19] *** Joins: umoot (d598a145@gateway/web/freenode/ip.213.152.161.69) [15:18:06] Hi! Anyone can confirm this behaviour? https://github.com/thestinger/linux-hardened/issues/27 [15:31:34] umoot: can you bisect it ? [15:31:44] umoot: is it systematic ? [15:32:44] aissen: it's always reproducible on my machine [15:32:54] umoot: finally, there might be a way to have logs with netconsole/serial console. But if it's easy to reproduce it would be faster to bisect. [15:33:28] umoot: oh, I see I asked you to bisect, but you didn't say if it's panicking on all linux-hardened tags [15:33:34] umoot: did you try just one version ? [15:34:36] aissen: as I wrote in issue description it happens with newest 4.11.1.a version. All previous versions were ok [15:35:05] aissen: vanilla 4.11.1 is also ok [15:35:07] umoot: oh, that's good to know. Do you know how to run a git bisect ? [15:35:30] aissen: unfortunately, no... [15:35:54] umoot: wait a minute [15:37:28] umoot: you can try reading https://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git [15:37:50] bisection should only take 4 or 5 compilations and reboots, if you have time [15:38:32] *** Joins: blueness (~blueness@gentoo/developer/blueness) [15:39:54] umoot: so you last booted with 4.11.f and suspend worked ? [15:41:02] aissen: yes 4.11.f works, 4.11.1 without hardened patch works too [15:41:08] umoot: so it should be roughly 7 steps according to what I'm seeing here [15:42:06] roughly 5 steps [15:44:41] umoot: So you do a "git bisect start 4.11.1.a v4.11.1 4.11.f" ; then compile, and if suspend/resume works you do a "git bisect good" , if it resume crashes you do a "git bisect bad". Then post the log of what you did to a pastebin so someone can look into it. [15:45:48] aissen: ok I'll look into it, thank you [15:49:19] *** Joins: catpig (~catpig@p54A57AFB.dip0.t-ipconnect.de) [15:58:21] weeee [16:03:38] where is strcat... hrm.... [16:21:07] sleeping probably [16:47:24] *** Quits: blueness (~blueness@gentoo/developer/blueness) (Quit: blueness) [16:49:48] *** Joins: dave0x6d (uid190567@gateway/web/irccloud.com/x-ryqhvjoqdgrjvdfb) [17:01:34] *** Quits: tigrmesh (~tigrmesh@archlinux/op/tigrmesh) (Ping timeout: 255 seconds) [17:04:04] *** Joins: citypw (~citypw@207.226.142.235) [17:15:47] *** Joins: blueness (~blueness@gentoo/developer/blueness) [17:37:20] timezones are a bitch [17:37:32] err, a pain [17:44:20] *** Quits: peetaur2 (~peter@i4DF67CD2.pool.tripleplugandplay.com) (Ping timeout: 260 seconds) [17:46:45] *** Joins: strcat (~strcat@archlinux/trusteduser/thestinger) [17:46:45] *** ChanServ sets mode: +o strcat [18:01:39] *** Quits: blueness (~blueness@gentoo/developer/blueness) (Quit: blueness) [18:04:32] *** Joins: _andyj_ (uid24906@gateway/web/irccloud.com/x-jyqhwwjhttrhcozn) [18:43:32] *** Joins: somis (~somis@149.56.153.182) [18:52:15] *** Joins: tigrmesh (~tigrmesh@archlinux/op/tigrmesh) [19:03:37] kees: I can't use BUG because I need fortify_panic to be noreturn to generate sane code [19:03:58] so I need a way to do an oops that's noreturn [19:04:06] for some reason BUG can be turned off [19:04:42] it's fine to do a kernel oops if there's a way to do it that always ends the current thread [19:05:55] is BUG noreturn when CONFIG_BUG is turned on at least? [19:06:17] it looks fairly per-arch and I don't know which if any guarantees I have from it [19:12:14] Hmm, good point about BUG [19:12:19] it _should_ be noreturn, though. [19:12:25] that's not something I've dug into yet [19:12:36] kees: I think I'll leave it as is and I can explain that if anyone asks [19:12:36] it kills the current kernel thread of execution, though. hmpf [19:12:39] yeah [19:12:41] agreed [19:13:10] kees: it might make sense to have a debug mode where it is not noreturn and warns instead of using panic *or* BUG [19:13:41] I think someone found an issue caught by the fortified strlcpy on resume [19:13:45] https://github.com/thestinger/linux-hardened/issues/27#issuecomment-301539817 [19:13:47] I'll see [19:16:27] *** Joins: blueness (~blueness@gentoo/developer/blueness) [19:16:37] __NO_FORTIFY on the resume code maybe? [19:17:02] kees: I'll give them a patch making it only warn [19:19:00] kees: I have mostly prepared another patch like the two I sent over the week-end to kernel-hardening, but unlike these two, the base code has changed between 4.11 and 4.12-rc1. Which tree should I target ? linux-next ? [19:22:05] Lionel_Debroux: at a minimum do work based on linus' master branch, which is where the mainline tags are made [19:22:15] depends on the workflow for the code you're working on [19:22:29] but you're always at least targeting master [19:23:47] Lionel_Debroux: if possible, use Linus's last release (v4.11 in this case). when it's something fast-moving or under lots of work, basing it off a specific linux-next tag is next-best. The latter can make merging hard, but it really depends on the code. [19:24:03] I'm digging myself out from under email right now, I'll try to find what you sent [19:27:05] *** Quits: b0untea (~b0untea@LStLambert-657-1-110-45.w92-154.abo.wanadoo.fr) (Quit: Leaving) [19:27:29] kees: last release by linus would be the rc though, or really just master where the tags are made [19:27:31] *shrug* [19:27:47] next is a PITA [19:27:58] it's probably already broken without your help ;) [19:32:12] *** Quits: blueness (~blueness@gentoo/developer/blueness) (Quit: blueness) [19:33:07] For now, I wrote it against Linus master, which was 4.12-rc1 at the time. [19:34:21] It's another companion change for RAP. [19:35:01] strcat: it can get complex. best is base release (v4.11). next best is v4.12-rc2, then v4.12-rc1, then -next [19:35:40] kees: why is 4.11 better than current master / rc ? [19:35:42] e.g. I keep my trees for -next based on the last -rc2 [19:36:06] the 'stable' releases are just another rc really [19:36:08] strcat: FWIU, Linus likes doing merges from there for new things. [19:36:12] ah [19:36:19] ignore stable for basing "new" stuff [19:36:37] for making sfr's job easiest for -next merges, -rc2 is after the merge window has flushed [19:36:49] -rc1 is kind of still "in the middle of lots of stuff going in" [19:37:00] and -next is a moving target [20:34:39] *** Joins: b0untea (~b0untea@78.192.96.126) [20:43:52] *** Quits: b0untea (~b0untea@78.192.96.126) (Read error: Connection reset by peer) [20:54:41] *** Joins: ph4nt0m[m] (hiyasibnsk@gateway/shell/matrix.org/x-hpvojtrbvesjhkce) [20:55:51] kees: unfortunately the error messages get a bit weird for strlcpy [20:55:58] since they come from memcpy or w/e [20:56:16] I need to tweak it anyway, the memcpy check isn't quite enough [20:57:50] BUG is effectively __builtin_unreachable and applies to the control flow branch rather than the whole function [20:58:11] kdave: yeah but it isn't guaranteed to be __noreturn [20:58:21] strcat: indeed [20:58:24] kdave: and I need that to use it in a __noreturn function to make it satisfy that [20:58:45] unless I make it conditional on CONFIG_BUG, but I don't think BUG is guaranteed to work sanely per-arch [20:58:48] what if an arch just warns? [20:58:50] strcat: can you point me to the code? [20:59:12] kdave: https://github.com/thestinger/linux-hardened/commit/e6c5ea972e1188eeb3a43b03d338e2a7b3a37fc1 [20:59:19] fortify_panic [20:59:23] I was curious about the BUG wrt noreturn relation so I may not have the right context [20:59:53] kdave: bug.h can't be included in string.h [21:00:06] and it needs something for early boot, before it's available [21:00:22] you can see I need to define this symbol for arch/x86/boot/compressed/misc.c for example [21:00:26] and there will be some other cases [21:02:35] kees: yeah strlcpy needs a minor tweak, it's checking for memcpy overflow but not the \0 it adds [21:02:39] so need to roll a custom check there [21:05:50] kdave: I'd like to do an oops instead of a panic there, essentially, but I want it to remain noreturn [21:11:05] *** Joins: kerframil (~kerframil@gentoo/user/kerframil) [21:24:08] kees: sadly I think it probably makes sense to move the strlen/strnlen code into a macro to reuse it without getting that extra function layer [21:24:10] ;\ [21:24:12] I'll deal with that later [21:26:06] I'll see in a sec [21:30:28] *** Quits: strcat (~strcat@archlinux/trusteduser/thestinger) (Quit: brb) [21:33:28] *** Joins: ch40s[m] (etherdisro@gateway/shell/matrix.org/x-fcikzgostqjpcmqq) [21:35:38] *** Joins: strcat (~strcat@archlinux/trusteduser/thestinger) [21:35:39] *** ChanServ sets mode: +o strcat [21:37:24] strcat: the noreturn for fortify_panic is required just to generate sane code? [21:37:39] kdave: it reduces the code size it adds [21:38:08] kdave: it'd be better if it could call BUG directly [21:38:18] although then the error is kinda incomprehensible [21:38:31] what I'm thinking: there are some sysclt knobs panic_on_XXX so would you want panic_on_fortify to be such sysctl? then there would have to be a switch and the whole function couldn't be noreturn [21:38:44] if the panic is not the only option [21:38:54] kdave: well, it really needs to end the thread [21:38:57] it shouldn't continue [21:39:04] hmm [21:39:34] for example, if it decided to continue, should it do the overflow, or refuse to do it and keep going, maybe truncating the copy [21:39:41] I think it needs to just stop [21:39:46] but it doesn't need to panic [21:39:56] if it can guarantee ending the thread [21:40:01] and I do think __noreturn is important there [21:40:24] in fact, I think what I'm doing now probably generates too much code, but I don't see a way to keep it usable while doing less [21:40:46] but I want to start simple, so not bloated, but not micro-optimized yet [21:41:02] if I started doing micro-optimization prematurely I'd make it harder to land [21:41:41] step 1 == landing basics, with __noreturn, and having people add fortify_panic impls for arch-specific areas needing it [21:42:10] yeah it looks to me pretty good in this form, I havent' seen the asm though [21:42:47] kdave: it inserts code to maybe 30% of memcpy, strlen, etc. locations and it's just 1 branch (for the mem* stuff at least) but there are a lot, so it matters [21:43:22] kdave: I have __func__ there b/c otherwise it's harder to tell what's going on [21:43:35] although that is more bloat ;p [21:43:57] sure, but when fortify fires you want to know where :) [21:44:42] maybe some section annotations or compiler hints to help to split hot/cold parts [21:44:51] kdave: well I has __cold on fortify_panic [21:44:52] I slightly doubt that mere likely/unlikely will help much [21:45:02] kdave: __cold makes any branch calling the function unlikely already [21:46:27] and it's supposed to put all the cold functions together, I guess below everything else, although I dunno where modules end up in relation to cold core code [21:47:11] kdave: I realized I can improve strncat/strlcpy code size though [21:47:16] w/e [21:47:28] stupid __func__ ;p [21:49:15] *** Quits: strcat (~strcat@archlinux/trusteduser/thestinger) (Quit: brb) [21:50:15] can __builtin_object_size checks be lifted from the function? if thery're supposed to be compile-time only, they should not generate any code if the arg lengths are known [21:50:44] *** Joins: strcat (~strcat@archlinux/trusteduser/thestinger) [21:50:44] *** ChanServ sets mode: +o strcat [21:51:06] kees: https://github.com/thestinger/linux-hardened/commit/ae3e1753dc61a50a65a57be28e8ffe2c9f62c0f9.patch new ver, has stricter strlcpy impl [21:51:31] it was allowing up to a 1 byte write overflow before since it only checked memcpy then set the \0 [21:51:52] so it was better than nothing but not actually fully checking it [21:54:35] making some minor changes to improve code size / errors a bit though [21:54:58] hm [21:55:13] actually w/e, it's good for now [21:55:36] iirc using a 'static inline' from this weird gnu extern inline will be bad [21:55:43] and I don't want a macro mess yet [22:16:12] strcat: have you seen this https://pastebin.com/raw/bzd40BVv ? could be related to issue 27 [22:17:24] kdave: try with https://github.com/thestinger/linux-hardened/releases/tag/4.11.1.b [22:17:33] kdave: I don't have the fixes for fortify stuff in the standalone patch [22:17:47] kdave: kees and I upstreamed some already, so I have some cherry-picked from upstream and some temporary workarounds [22:18:17] kdave: https://github.com/thestinger/linux-hardened/commit/0379fd08610fec0cff30fb515c70a2cb521492bd is prob that [22:18:21] *** Joins: decoy_N3g3v (~decoy_N3g@KD118157015215.ppp-bb.dion.ne.jp) [22:18:55] I think kees got it fixed properly upstream 'somewhere' but I'll wait for the actual fixes since they are spread out in different trees [22:19:09] yes that's the memcpy call [22:19:46] kdave: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=kspp/fortify&id=95d589f21b3aef757f0eb3d0224b78648a4b22d2 is the proper fix [22:20:26] most were abuse of memcpy on string constants using dest buffer size, so read overflows copying some junk from rodata [22:23:31] *** Quits: umoot (d598a145@gateway/web/freenode/ip.213.152.161.69) () [22:26:31] I see, thanks [22:37:46] *** Quits: decoy_N3g3v (~decoy_N3g@KD118157015215.ppp-bb.dion.ne.jp) (Read error: Connection reset by peer) [22:41:42] *** Joins: decoy_N3g3v (~decoy_N3g@89.160.93.123) [22:46:40] *** Quits: decoy_N3g3v (~decoy_N3g@89.160.93.123) (Ping timeout: 240 seconds) [22:49:35] *** Quits: dave0x6d (uid190567@gateway/web/irccloud.com/x-ryqhvjoqdgrjvdfb) (Quit: Connection closed for inactivity) [22:55:21] *** Joins: dave0x6d (uid190567@gateway/web/irccloud.com/x-cfcrraceppddejut) [22:56:15] *** Joins: blueness (~blueness@gentoo/developer/blueness) [23:08:14] kdave: I expect that bug that's reported is a runtime strlcpy error [23:08:25] b/c it's the only one I added since the last ver they say worked [23:08:33] and I doubt other changes could have done it... [23:08:38] * strcat shrugs [23:19:04] *** Joins: umoot (d598a268@gateway/web/freenode/ip.213.152.162.104) [23:21:04] *** Joins: b0untea (~b0untea@78.192.96.126) [23:23:22] kdave: meh they say it happens without CONFIG_FORTIFY_SOURCE but I can't really see how that's possible [23:29:38] they say 4.11.f worked, 4.11.1.a doesn't [23:29:42] that's strange [23:29:44] so there are only a couple changes [23:30:06] fortify changes (which are ruled out, if I trust that they didn't make a mistake) [23:30:15] upstream 4.11.1 changes [23:30:23] and a couple __ro_after_init [23:32:54] __supported_pte_mask and kernel_set_to_readonly __ro_after_init are the only other changes other than fortify between those [23:33:06] oh and the extra latent entropy thing [23:33:20] but that's not enabled by default [23:39:51] *** Quits: blueness (~blueness@gentoo/developer/blueness) (Quit: blueness) [23:42:31] this was meant to be collaboratively but it seems I'm doing more than I expected :\ [23:42:35] collaborative* [23:43:55] sorry I can't help, I need to refresh the code and some parts I don't really understand [23:45:10] it'd help if someone could replicate that hibernate bug [23:45:27] I wonder if they're using xen [23:46:06] *** Joins: blueness (~blueness@gentoo/developer/blueness) [23:46:29] I have a spare notebook here, will try to reproduce it [23:47:12] kdave: yeah lots of the code is really complicated, that's why I want to extract it bit by bit [23:47:22] strcat: hi, I'm reporter of this bug [23:47:39] umoot: are you using a VM or real hw? [23:47:49] strcat: real hp laptop [23:47:57] ok so not this xen thing I see [23:48:29] umoot: can you please paste .config? [23:48:39] strcat: i'm compiling 4.11.1 with 4.11.f hardened now [23:48:48] umoot: k if that work it narrows this down a lot [23:49:21] umoot: I can make a patch undoing half of the 4.11.a changes to try, then maybe another, and then we should know which it is, at least [23:50:01] there are 4 changes: extra latent entropy, __ro_after_init for __supported_pte_mask, __ro_after_init for kernel_set_to_readonly (along with moving where it's set) and the fortify changes [23:50:09] so the fortify changes should be ruled out since you tried with it disabled [23:51:11] I don't think suspend works on my desktop with vanilla so... [23:51:23] I could try on my laptop [23:51:39] strcat: here's config https://ghostbin.com/paste/pa69p [23:51:44] kdave: [23:52:24] ah it's the arch linux one [23:52:32] strcat: it's copied from arch, I disabled ipv6 an unused modules