[12:07] <TJ-> I am modifying the build system to build for MCYRIXIII (no PAE, CMOV, or CX8) which is technically a real i486 build, a variation of the i386 (really i686) arch. Would it make sense to make it a flavour of i386 or create a new arch, as in ./debian.master/config/i486/ ?
[12:45] <apw> TJ-, its a variation of i386 i assume, so it'd want to use that kernel arch
[12:45] <apw> TJ-, though will userspace even work on that, given it is also at liberty to assume CMOV etc
[12:46] <TJ-> apw: The issue I was wondering about is that the i386 flavours all have the 64 bit support flags enabled
[12:47] <TJ-> apw: So either I'd need an explicit over-ride from =Y to =N or an entirely different arch
[12:48] <apw> TJ-, the arch there i386 matches the debian arch you are trying to target, not the kernel arch per-se
[12:49] <apw> TJ-, yes you will make a heap of mess in the config split, but, whatever, thats not your problem
[12:49] <TJ-> apw: Userspace will be fine; Currently I'm using a Debian install but this is for low power pseudo-embedded devices doing simple network monitoring tasks and I'd like to keep the entire estate on the same ubuntu server release
[12:49] <TJ-> apw: I thought it did (match the packaging arch) which is why I asked before wasting time :)
[12:50] <apw> TJ-, i am not sure because debian works, that ubuntu uspace would work with it, unless you are saying you have rammed a debian kernel into our userspace and it did work
[12:50] <apw> which would be a sensible test
[12:50] <apw> as we do not necessarily compiler our libraries including libc with the same lower limits
[12:51] <apw> h/w support wise
[12:51] <TJ-> apw: Pure Debian for the original test, now using network boot with rpld -> iPXE -> cobbler -> Ubuntu Server i386 with custom kernel alternatives being tested.
[12:52] <TJ-> apw: Once I can get an Ubuntu kernel to boot, I'll sort out userspace if needed :)
[12:53] <TJ-> apw: So my challenge is to modify debian.master/config/i386/ to override some of the .common. configs that expect 64-bit (PAE) support
[12:54] <TJ-> apw: Maybe I should go back in the history to see how the PAE/non-PAE split was done in 12.04 
[12:54] <apw> TJ-, well first add your own flavour, and say copy config.flavour.generic into it, then start adding the "differences" you want
[12:54] <apw> to that same file, and running update configs until you have a config which works
[12:54] <apw> running debian/rules updateconfigs
[12:55] <apw> TJ-, if the release you are basing on has -lowlatency that shows the places you need to be concious off when making a -i486 or whatever you call it
[12:56] <TJ-> apw: The adding isn't an issue ... it's the taking-away that I'm wondering about - can't just have commented entries in the new flavour, got to over-ride the incompatible flags. I'll play about with it now I know to stick with the i386 arch - thanks alot :)
[12:56] <TJ-> apw: Yeah, got/using low-latency (working off 14.04)
[12:56] <apw> TJ-, "# CONFIG_FOO is not set" is not (contrary to its appearance) a comment, it is the written equivalent of "CONFIG_FOO=n"
[12:57] <apw> and will override an =y/m to off
[12:57] <apw> TJ-, additionally as you do this i _strongly_ recommend you keep a copy of the "total overrides" you have added to that file
[12:58] <TJ-> apw: really? I always thought it was ignored by the build system?
[12:58] <TJ-> apw: Yeah - it's all committed in git :)
[12:58] <apw> as when we change the config under you, you can "cat config.flavour.generic my-overrides >config.flavour.i486; debian/rules updateconfigs" to reapply your delta
[12:59] <apw> TJ-, really yes, the latest entry is taken for any value and that includes the "is not set" specifiers
[12:59] <apw> thats why you find them in the config fragments at all
[13:04] <TJ-> apw: aha, that helps! I did read earlier how to use the build scripts to generate the flavour ./.config but can't find it now - is it a simple debian/rules <some-target-name>  or more involved ?
[13:05] <apw> to find out what the raw configs look like, debian/rules genconfigs and look in CONFIGS/*
[13:06] <TJ-> apw: Thanks :) the various wiki pages aren't entirely clear on this aspect
[13:06] <apw> TJ-, to be honest we don't want it to be too easy, as you really want to be knowledgable before you even think about taking on maintenance of a kernel derivative
[13:07] <apw> TJ-, if you end up doing this as a derivative kernel, there is some support for "derived configs" in the linux-lowlatency kernel which was separate in a couple of releeases, where the rebase act fixes the configs for you in the majority case.
[13:08] <apw> it is essentially doing what i proposed here, given an accumulated "these must be these values i care not about anything else" being applied relative to generic
[13:08] <TJ-> apw: I've been doing custom kernel builds/maintenance for 10 years or so, but it's a while since I worked with the Ubuntu build scripts and things have changed a lot there
[13:08] <apw> kind of thing.  which worked pretty well with things like you are changing, fundamental values which never change
[13:09] <apw> TJ-, we rarely stay still for long, where is the fun in that
[13:10] <TJ-> Re-inventing the wheel gets boring :)
[13:14] <apw> yep derivative kernels are a pain to maintain for sure
[13:32] <thms_> TCP timestamps enabled on a default Ubuntu server, is a "MEDIUM RISK" according to vulnerability scanners like OpenVAS, because it provides critical info to hackers about the system. But the timestamps provide a lot of very useful features as well, so my question is - Is it possible to enable randomized TCP timestamps in some way? Or should I disable completely? Or ignore the warnings?
[13:35] <apw> thms_, not sure i know off the top of my head ... jjohansen ^ ?
[13:41] <jjohansen> thms_, apw: I am not aware of away to do that, personally I would put the TCP timestaps issue as low risk, it allows getting the system uptime and boot time, and disabling it will slow down your tcp connections
[13:41] <thms_> apw there seem to be a lot of suggestions to simply turn them off - but since it enabled by default in almost all distributions, including firewall distros, there has to be a better way...
[13:42] <jjohansen> as long as you are keeping your system up to date, you should be okay.  If you aren't rebooting into new security kernels or live patching it becomes more of a problem
[13:42] <apw> thms_, from what i can see in a very cursory look, is that they are either on or not on
[13:42] <thms_> right...
[13:42] <jjohansen> that agrees with what I know
[13:43] <thms_> I'v found that Sophos, a Linux based firewall distro has timestamps on by default, but it seems to randomize the numbers in some way...
[13:44] <thms_> Thanks anyways :-)
[13:44] <jjohansen> thms_: grsecurity is carrying a patch to do that
[13:45] <apw> jjohansen, and that tells me to stop looking to see if it is possible :)
[13:45]  * thms_ goes looking at grsecurity
[13:45] <apw> jjohansen, got a pointer to that patch, purely academic interest, i wonder if it is complex
[13:45] <jjohansen> and it looks like openbsd
[13:46] <thms_> I think the 'bsd's all have some implementation of this
[13:46] <jjohansen> apw: nope grsecurity is one big ugly flat patch, I just found an email referencing it
[13:47] <apw> oh those people
[13:47] <jjohansen> actually I'm not sure if they have it, that mail was that have a working proof of concept
[13:48] <apw> yeah i see the same, though if that description is right, it may be a simple thing to set tsoffset or something to != 0
[13:56] <thms_> I won't pretend to fully understand every aspect of the timestamping stuff, but the proposed patch here, looks very simple: https://grsecurity.net/~spender/random_timestamp.diff - although, to my knowledge, the "randomness" should probably be set per connection
[13:57] <thms_> but something like this would probably be a good start - and not causing new problems either (the per connection randomization might be a little more tricky to get right?)
[14:01] <cking> amitk, how's idlestat progression?  any hints when version 0.4 will land?
[14:01] <cking> s/progression/progressing/
[14:02] <apw> thms_, it is not clear you couldn't just load that random number into tsoffset instead of =0, but then i am no expert
[14:03] <apw> thms_, making it per connection instead ...
[14:04] <smb> jibel, Did you already change the proxy settings for the dkms test host. Asking because I still see them all failing while they should succeed (and picking a random log still showed the fw download as the issue)
[14:04] <thms_> apw, oh, there's a tsoffset for the connection initialization code?
[14:04] <smb> jibel, that is dahdi dkms package
[14:04]  * thms_ shamefully admits to not having done his homework :-|
[14:05] <apw> thms_, if i am reading things right, each socket has its own offset, i have no idea what is really used for, but it is thrown into the mix when making the timestamp
[14:05] <apw> thms_, so it is possible one could use that in some way, perhaps
[14:05] <apw> thms_, the good thing about a single offset such as in the grc version is that is is more spec friendly for the various optimisations
[14:06] <jibel> smb, no, I didn't have time to do it yet. I'll let you know once it's done.
[14:06] <thms_> apw, right; simply generating a random number instead...
[14:06] <smb> jibel, Ah ok. Yeah, thanks.
[14:06] <thms_> apw, my thought exactly - although per session seems like the "proper" solution to this
[14:06] <apw> thms_, just not sure what effect that has, given it is there for something else, for "repair", but ... who knows what that is ... checkpoint restore perhaps
[14:07] <thms_> right..
[14:09] <apw> if it is for CPR then, it would be a good candidate
[14:10] <thms_> CPR?
[14:11] <apw> check-point-restore
[14:11] <thms_> Never heard of it but seems handy :-)
[14:12] <apw> yeah some processes can be potted and reloaded on another system, one of the things they can in theory carry over
[14:12] <apw> is network connections, and the timestamps would need to be those in use on the original system
[14:12] <apw> and that would fit well with it being a sockopt which is the only thing which can change it
[14:13] <apw> as you would make the socket, and fix it, before giving it back to the process image you are loading
[14:14] <thms_> exactly... sounds cool... what's it used for? loadbalancing processes or debugging?
[14:15] <smb> live migration of containers
[14:15] <thms_> of course... nice
[16:55] <jsalisbury> ##
[16:55] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:55] <jsalisbury> ##
[18:05] <amitk>  /quit