Your message dated Sat, 02 Sep 2017 12:03:46 +0200 with message-id <[email protected]> and subject line Re: Bug#874034: Debian should disable legacy vsyscall has caused the Debian Bug report #874034, regarding Debian should disable legacy vsyscall to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 874034: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874034 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: kernel The current Debian kernels support the legacy vsyscall method. This can be a security risk and is not needed within a modern system. Background: vsyscall was a method to map commonly used kernel functions into application space to a fixed address. It has been replaced by the more secure and flexible vdso mechanism. vsyscall is problematic, because it maps code to a fixed address, thus making ASLR (Address Space Layout Randomization) less effective. Due to this vsyscall has been redesigned into an "emulated" mode (which is what Debian's current kernels support) that reduces the amount of code and thus the attack surface. But still it's some code mapped to a fixed address and a legacy feature that shouldn't be needed any more. Currently Debian kernels have the option CONFIG_LEGACY_VSYSCALL_EMULATE=y This should be disabled and instead CONFIG_LEGACY_VSYSCALL_NONE=y should be set. Please note that this would still not remove the functionality, it would just disable it by default. By passing vsyscall=emulate to the boot command line users could still reactivate it. (By setting CONFIG_X86_VSYSCALL_EMULATION=n alternatively it could also be disabled entirely.) Compatibility risks: Modern glibc versions don't use vsyscall, so dynamic binaries won't be affected by this change (unless you happen to try to run a very old glibc version within a modern debian). Users trying to run very old static binaries may be negatively affected, as these may no longer run if they try to use vsyscall. Given that the release of Debian Buster is still some time away I think now would be a good time to implement such a change in unstable/testing, making it likely that potential problems would be discovered long before Buster gets released.
--- End Message ---
--- Begin Message ---Am 02.09.2017 um 11:32 schrieb Hanno Böck: > Package: kernel This is not a valid package, please use src:linux instead. > The current Debian kernels support the legacy vsyscall method. This can > be a security risk and is not needed within a modern system. > > Background: > vsyscall was a method to map commonly used kernel functions into > application space to a fixed address. It has been replaced by the more > secure and flexible vdso mechanism. > > vsyscall is problematic, because it maps code to a fixed address, thus > making ASLR (Address Space Layout Randomization) less effective. Due to > this vsyscall has been redesigned into an "emulated" mode (which is > what Debian's current kernels support) that reduces the amount of code > and thus the attack surface. But still it's some code mapped to a fixed > address and a legacy feature that shouldn't be needed any more. > > Currently Debian kernels have the option > CONFIG_LEGACY_VSYSCALL_EMULATE=y > This should be disabled and instead > CONFIG_LEGACY_VSYSCALL_NONE=y > should be set. That is already the case in buster: ,---- | linux (4.10~rc6-1~exp1) experimental; urgency=medium | [...] | * [amd64] Enable LEGACY_VSYSCALL_NONE instead of LEGACY_VSYSCALL_EMULATE | (Closes: #852620). This breaks (e)glibc versions < 2.14 and dietlibc | versions < 0.33. It can be reverted using the kernel parameter: | vsyscall=emulate `---- Seems nothing needs to be done, so I'm closing this bug. Cheers, Sven
--- End Message ---
