Re: Minutes of the Debian linux-2.6 Group Meeting
On Thu, Nov 11, 2010 at 13:52:12 +, maximilian attems wrote: LSM: Enable AppArmor? as well as/instead of Tomoyo? --- As the LSM need to be built we can't enable them. This needs a technical solution were code can be disregarded as init sections or similar. AppArmor seems more popular as Opensuse and Ubuntu uses it. Technicaly Tomoyo is said to be cleaner. What do you mean by can't here? You can build _all_ of them, actually. The active LSM is just selected at boot-time through the kernel command line arguments. If it's a concern over kernel size, upstream specifically removed the ability to make the LSM modular, so this means that no additional LSMs will ever be available in Debian? NX bit emulation and 32-bit mmap randomization -- We don't want to carry intrusive patches. The NX patch was rejected as such by upstream and thus we won't take it either. Why? These patches are well maintained, and touch areas of the kernel that do not change much (making them very easy to merge). Why leave non-PAE x86 users out in the code when so many other distros use some form of this patchset? I've worked to make sure they only touch CONFIG_X86_32, so they're extremely minimal. Currently we recommend PAE for bigger boxes but do not default to it. Action item by bwh and waldi to default Debian Installer to it and deprecate non PAE 686. This sounds great, regardless. Upstream status of the other patch is unknown, maks will consult Kees. In my mind, they[1] are a single patch -- the 32-bit mmap randomization is better named ASCII Armor ASLR, which doesn't have much value, IMO. The entropy is extremely low compared to upstream ASLR, but it would be actually 0 if left out in the nx-emu case. As such, it is only enabled on systems that are using nx-emu. I intend to try to get it upstreamed, but it's pretty far down on my TODO list[1]. Thanks, -Kees [1] http://git.kernel.org/?p=linux/kernel/git/frob/linux-2.6-roland.git;a=shortlog;h=refs/heads/fedora/x86-nx-emulation http://git.kernel.org/?p=linux/kernel/git/frob/linux-2.6-roland.git;a=shortlog;h=refs/heads/fedora/32bit-mmap-exec-randomization (this one is still missing one additional patch from me...) [2] https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Upstream%20Hardening -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101118192339.gf13...@outflux.net
Re: Minutes of the Debian linux-2.6 Group Meeting
On Thu, Nov 18, 2010 at 11:23:39 -0800, Kees Cook wrote: On Thu, Nov 11, 2010 at 13:52:12 +, maximilian attems wrote: LSM: Enable AppArmor? as well as/instead of Tomoyo? --- As the LSM need to be built we can't enable them. This needs a technical solution were code can be disregarded as init sections or similar. AppArmor seems more popular as Opensuse and Ubuntu uses it. Technicaly Tomoyo is said to be cleaner. What do you mean by can't here? You can build _all_ of them, actually. The active LSM is just selected at boot-time through the kernel command line arguments. If it's a concern over kernel size, upstream specifically removed the ability to make the LSM modular, so this means that no additional LSMs will ever be available in Debian? See the second sentence. This needs a technical solution where code can be disregarded as init sections or similar. So your kernel has a bunch of LSMs builtin, but at boot time one of them is selected and you release the memory taken by the rest of them instead of keeping the code lying there unused. Cheers, Julien signature.asc Description: Digital signature
Re: Minutes of the Debian linux-2.6 Group Meeting
Hi, On Thu, Nov 18, 2010 at 08:37:44PM +0100, Julien Cristau wrote: On Thu, Nov 18, 2010 at 11:23:39 -0800, Kees Cook wrote: On Thu, Nov 11, 2010 at 13:52:12 +, maximilian attems wrote: LSM: Enable AppArmor? as well as/instead of Tomoyo? --- As the LSM need to be built we can't enable them. This needs a technical solution were code can be disregarded as init sections or similar. AppArmor seems more popular as Opensuse and Ubuntu uses it. Technicaly Tomoyo is said to be cleaner. What do you mean by can't here? You can build _all_ of them, actually. The active LSM is just selected at boot-time through the kernel command line arguments. If it's a concern over kernel size, upstream specifically removed the ability to make the LSM modular, so this means that no additional LSMs will ever be available in Debian? See the second sentence. This needs a technical solution where code can be disregarded as init sections or similar. So your kernel has a bunch of LSMs builtin, but at boot time one of them is selected and you release the memory taken by the rest of them instead of keeping the code lying there unused. Right, my point was that upstream expressly moved away from that ability, which means, if combined with the other only if in upstream statements, the Debian kernel will only ever be built with one LSM. Now, don't get me wrong, I'd hugely prefer there be an __init-like way to handle this, and it actually touches on the constification work too. Still, blocking until the feature exists seems unfun. :) Thanks, -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101118200333.gg13...@outflux.net
Re: Minutes of the Debian linux-2.6 Group Meeting
On Thu, Nov 11, 2010 at 01:52:12PM +, maximilian attems wrote: [...] Automated tests --- This is a pressing task, we should know sooner if the specific branch compiles and boots. waldi shouts for reprepro, sbuild and wannbuild. Build server needed between 6-12 hours and back then we didn't have debug yet. People were using and testing our builds. Action item by Ben to poke Vince for a Debian solution with enough horse power and no bandwidth troubles. Also the automated tests proposed at the kernel summit are to be watched. fyi, hp was hosting a system for d-i testing that has recently become available. Its a dual socket, 4-core xeon 2.33GHz system w/ 8 G of RAM and 8x 15K RPM SAS drives (2 of which may be failing.. SMART status is vague). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101117160835.ga19...@dannf.org
Re: Minutes of the Debian linux-2.6 Group Meeting
On Thu, 11 Nov 2010, Marco d'Itri wrote: On Nov 11, maximilian attems m...@stro.at wrote: waldi proposes to remove old untouched stuff like ax25 and atm. Remove from where? The ATM stack is needed to support USB DSL modems, and while the code is not beautiful I think it can be considered mature. ok thanks for the feedback. the more striking examples that got lost in the transcript, are drivers that we are building due to them beeing modular, but that can't be possible used. The cost of it has not yet been evaluated. We need a server box with good cooling to run benchmarks with it. I can offer temporary access to developers to blade servers with 12 cores (hopefully soon with 48) and plenty of RAM. Would a KVM guest work for you? The hosts run RHEL since it is more stable (sorry...), I could temporarily install Debian on one but it would take more time. Ben did take that action item irc, guess this can be sorted out. -- maks -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101114162609.ga11...@stro.at
Re: Minutes of the Debian linux-2.6 Group Meeting
On Nov 11, maximilian attems m...@stro.at wrote: waldi proposes to remove old untouched stuff like ax25 and atm. Remove from where? The ATM stack is needed to support USB DSL modems, and while the code is not beautiful I think it can be considered mature. The cost of it has not yet been evaluated. We need a server box with good cooling to run benchmarks with it. I can offer temporary access to developers to blade servers with 12 cores (hopefully soon with 48) and plenty of RAM. Would a KVM guest work for you? The hosts run RHEL since it is more stable (sorry...), I could temporarily install Debian on one but it would take more time. -- ciao, Marco signature.asc Description: Digital signature
Re: Minutes of the Debian linux-2.6 Group Meeting
Thanks maks, tiny update from the Xorg side: maximilian attems m...@stro.at (11/11/2010): Debian intel xorg driver is missing patch to bail out earlier when kms is off so the server will fall back to vesa, instead of erroring out. 455f2939 landed upstream, will be cherry-picked: http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=455f2939a661764ebb8d1747d44e16a0a8937808 Radeon KMS is a known regression from UMS (can't change backlight, and can't suspend/resume at least on powerpc). xorg should currently remove modeset on these archs. Done in 1:6.13.1-2+squeeze1, needs an unblock (#603165). Mraw, KiBi. signature.asc Description: Digital signature
Re: Minutes of the Debian linux-2.6 Group Meeting
On 11/11/2010 04:26 PM, Cyril Brulebois wrote: maximilian attems m...@stro.at (11/11/2010): Radeon KMS is a known regression from UMS (can't change backlight, and can't suspend/resume at least on powerpc). xorg should currently remove modeset on these archs. Done in 1:6.13.1-2+squeeze1, needs an unblock (#603165). Unblocked now. Cheers, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cdc0f29.5040...@dogguy.org
