=== psivaa-holiday is now known as psivaa [12:07] 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] TJ-, its a variation of i386 i assume, so it'd want to use that kernel arch [12:45] TJ-, though will userspace even work on that, given it is also at liberty to assume CMOV etc [12:46] apw: The issue I was wondering about is that the i386 flavours all have the 64 bit support flags enabled [12:47] apw: So either I'd need an explicit over-ride from =Y to =N or an entirely different arch [12:48] TJ-, the arch there i386 matches the debian arch you are trying to target, not the kernel arch per-se [12:49] TJ-, yes you will make a heap of mess in the config split, but, whatever, thats not your problem [12:49] 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] apw: I thought it did (match the packaging arch) which is why I asked before wasting time :) [12:50] 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] which would be a sensible test [12:50] as we do not necessarily compiler our libraries including libc with the same lower limits [12:51] h/w support wise [12:51] 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] apw: Once I can get an Ubuntu kernel to boot, I'll sort out userspace if needed :) [12:53] 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] apw: Maybe I should go back in the history to see how the PAE/non-PAE split was done in 12.04 [12:54] TJ-, well first add your own flavour, and say copy config.flavour.generic into it, then start adding the "differences" you want [12:54] to that same file, and running update configs until you have a config which works [12:54] running debian/rules updateconfigs [12:55] 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] 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] apw: Yeah, got/using low-latency (working off 14.04) [12:56] 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] and will override an =y/m to off [12:57] 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] apw: really? I always thought it was ignored by the build system? [12:58] apw: Yeah - it's all committed in git :) [12:58] 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] TJ-, really yes, the latest entry is taken for any value and that includes the "is not set" specifiers [12:59] thats why you find them in the config fragments at all [13:04] 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 or more involved ? [13:05] to find out what the raw configs look like, debian/rules genconfigs and look in CONFIGS/* [13:06] apw: Thanks :) the various wiki pages aren't entirely clear on this aspect [13:06] 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] 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] 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] 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] kind of thing. which worked pretty well with things like you are changing, fundamental values which never change [13:09] TJ-, we rarely stay still for long, where is the fun in that [13:10] Re-inventing the wheel gets boring :) [13:14] yep derivative kernels are a pain to maintain for sure [13:32] 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] thms_, not sure i know off the top of my head ... jjohansen ^ ? [13:41] 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] 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] 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] thms_, from what i can see in a very cursory look, is that they are either on or not on [13:42] right... [13:42] that agrees with what I know [13:43] 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] Thanks anyways :-) [13:44] thms_: grsecurity is carrying a patch to do that [13:45] jjohansen, and that tells me to stop looking to see if it is possible :) [13:45] * thms_ goes looking at grsecurity [13:45] jjohansen, got a pointer to that patch, purely academic interest, i wonder if it is complex [13:45] and it looks like openbsd [13:46] I think the 'bsd's all have some implementation of this [13:46] apw: nope grsecurity is one big ugly flat patch, I just found an email referencing it [13:47] oh those people [13:47] actually I'm not sure if they have it, that mail was that have a working proof of concept [13:48] 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] 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] 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] amitk, how's idlestat progression? any hints when version 0.4 will land? [14:01] s/progression/progressing/ [14:02] 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] thms_, making it per connection instead ... [14:04] 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] apw, oh, there's a tsoffset for the connection initialization code? [14:04] jibel, that is dahdi dkms package [14:04] * thms_ shamefully admits to not having done his homework :-| [14:05] 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] thms_, so it is possible one could use that in some way, perhaps [14:05] 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] smb, no, I didn't have time to do it yet. I'll let you know once it's done. [14:06] apw, right; simply generating a random number instead... [14:06] jibel, Ah ok. Yeah, thanks. [14:06] apw, my thought exactly - although per session seems like the "proper" solution to this [14:06] 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] right.. [14:09] if it is for CPR then, it would be a good candidate [14:10] CPR? [14:11] check-point-restore [14:11] Never heard of it but seems handy :-) [14:12] yeah some processes can be potted and reloaded on another system, one of the things they can in theory carry over [14:12] is network connections, and the timestamps would need to be those in use on the original system [14:12] and that would fit well with it being a sockopt which is the only thing which can change it [14:13] as you would make the socket, and fix it, before giving it back to the process image you are loading [14:14] exactly... sounds cool... what's it used for? loadbalancing processes or debugging? [14:15] live migration of containers [14:15] of course... nice [16:55] ## [16:55] ## Kernel team meeting in 5 minutes [16:55] ## [18:05] /quit === jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues December 2nd, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! If the question is should I file a bug for something, likely you can assume yes.