| === psivaa-holiday is now known as psivaa | ||
| 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:07 |
|---|---|---|
| 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:45 |
| TJ- | apw: The issue I was wondering about is that the i386 flavours all have the 64 bit support flags enabled | 12:46 |
| TJ- | apw: So either I'd need an explicit over-ride from =Y to =N or an entirely different arch | 12:47 |
| apw | TJ-, the arch there i386 matches the debian arch you are trying to target, not the kernel arch per-se | 12:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| TJ- | apw: Once I can get an Ubuntu kernel to boot, I'll sort out userspace if needed :) | 12:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 12:59 |
| 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:04 |
| apw | to find out what the raw configs look like, debian/rules genconfigs and look in CONFIGS/* | 13:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| apw | TJ-, we rarely stay still for long, where is the fun in that | 13:09 |
| TJ- | Re-inventing the wheel gets boring :) | 13:10 |
| apw | yep derivative kernels are a pain to maintain for sure | 13:14 |
| 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:32 |
| apw | thms_, not sure i know off the top of my head ... jjohansen ^ ? | 13:35 |
| 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:41 |
| 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:42 |
| 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:43 |
| thms_ | Thanks anyways :-) | 13:44 |
| jjohansen | thms_: grsecurity is carrying a patch to do that | 13:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:56 |
| 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?) | 13:57 |
| cking | amitk, how's idlestat progression? any hints when version 0.4 will land? | 14:01 |
| cking | s/progression/progressing/ | 14:01 |
| 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:02 |
| apw | thms_, making it per connection instead ... | 14:03 |
| 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:04 | |
| 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:05 |
| 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:06 |
| thms_ | right.. | 14:07 |
| apw | if it is for CPR then, it would be a good candidate | 14:09 |
| thms_ | CPR? | 14:10 |
| apw | check-point-restore | 14:11 |
| thms_ | Never heard of it but seems handy :-) | 14:11 |
| 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:12 |
| apw | as you would make the socket, and fix it, before giving it back to the process image you are loading | 14:13 |
| thms_ | exactly... sounds cool... what's it used for? loadbalancing processes or debugging? | 14:14 |
| smb | live migration of containers | 14:15 |
| thms_ | of course... nice | 14:15 |
| jsalisbury | ## | 16:55 |
| jsalisbury | ## Kernel team meeting in 5 minutes | 16:55 |
| jsalisbury | ## | 16:55 |
| amitk | /quit | 18:05 |
| === 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. | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!