Re: [PATCH] Undo some of the pseudo-security madness
At Sat, 24 Feb 2007 10:51:20 +0100, Florian Weimer wrote: > > > Randomisation has nothing to do with C. In fact from a C perspective the > > compiler and linker do a lot of work to deal with ELF and loading code at > > arbitary addresses for dynamic linking and the like, not the user and > > not as language constructs. Perhaps the Lisp universe should wake up and > > meet the 1980s 8) > > Uhm, C++ folks and others have run into loader performance issues due > to the way DSOs are handled. The problem is more severe in the lisp > context because a typical image contains hundreds of thousands of > small objects on startup. Well: [EMAIL PROTECTED]:/mnt/shared/video1 # cat /proc/`pgrep sbcl | head -n1`/maps | wc -l 1378 regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
At Sat, 24 Feb 2007 10:40:51 +0100, Florian Weimer wrote: > > * Samium Gromoff: > > > Lisp environments can produce standalone executables > > If you've got a stand-alone executable, you don't need MAP_FIXED. The > ELF loader maps the program at a fixed address anyway (at least on > i386 and x86_64, I haven't checked others). Not so. The thing is that the picture is of two pieces: - the executable - the unrelocatable lisp core (which is unrelocatable by the virtue of non-PIC code) which is mapped into the AS of the executable. It is the latter which breaks, as its map can overlap with randomized pieces of the executable (along with its libraries). > AFAIK, PolyML has recently made the switch to stand-alone executables > for this reason. regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
At Sat, 24 Feb 2007 10:40:51 +0100, Florian Weimer wrote: * Samium Gromoff: Lisp environments can produce standalone executables If you've got a stand-alone executable, you don't need MAP_FIXED. The ELF loader maps the program at a fixed address anyway (at least on i386 and x86_64, I haven't checked others). Not so. The thing is that the picture is of two pieces: - the executable - the unrelocatable lisp core (which is unrelocatable by the virtue of non-PIC code) which is mapped into the AS of the executable. It is the latter which breaks, as its map can overlap with randomized pieces of the executable (along with its libraries). AFAIK, PolyML has recently made the switch to stand-alone executables for this reason. regards, Samium Gromoff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
At Sat, 24 Feb 2007 10:51:20 +0100, Florian Weimer wrote: Randomisation has nothing to do with C. In fact from a C perspective the compiler and linker do a lot of work to deal with ELF and loading code at arbitary addresses for dynamic linking and the like, not the user and not as language constructs. Perhaps the Lisp universe should wake up and meet the 1980s 8) Uhm, C++ folks and others have run into loader performance issues due to the way DSOs are handled. The problem is more severe in the lisp context because a typical image contains hundreds of thousands of small objects on startup. Well: [EMAIL PROTECTED]:/mnt/shared/video1 # cat /proc/`pgrep sbcl | head -n1`/maps | wc -l 1378 regards, Samium Gromoff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit
At Tue, 23 Jan 2007 16:16:12 -0500, Jakub Jelinek wrote: > > On Wed, Jan 24, 2007 at 12:06:45AM +0300, Samium Gromoff wrote: > > Should we introduce per-arch asm/elf.h files to hold the relevant flag > > definitions then? > > On some architectures there are no bits left. On others you'd need to go > through whomever maintains the relevant psABI to get a bit officially > allocated. Really, it is very bad idea to use e_flags for this. How does one find the relevant maintainers? Even just the specs are harder to find in the authoritative location, given the OSDL and FSG merge: the psabi documents at http://www.linux-foundation.org/spec/refspecs/ all 404... > If all you care about is running setuid LISP programs, you'd much better put > your energy into fixing the buggy ELF dumper in it. > > Jakub regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit
At Tue, 23 Jan 2007 16:16:12 -0500, Jakub Jelinek wrote: > > On Wed, Jan 24, 2007 at 12:06:45AM +0300, Samium Gromoff wrote: > > Should we introduce per-arch asm/elf.h files to hold the relevant flag > > definitions then? > > On some architectures there are no bits left. On others you'd need to go > through whomever maintains the relevant psABI to get a bit officially > allocated. Really, it is very bad idea to use e_flags for this. Currently arch_align_stack() and mmap_base() perform randomisation only on x86 and x86_64, so it is only two architectures anyway... > If all you care about is running setuid LISP programs, you'd much better put > your energy into fixing the buggy ELF dumper in it. > > Jakub regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit
At Tue, 23 Jan 2007 15:50:18 -0500,
Jakub Jelinek wrote:
>
> On Tue, Jan 23, 2007 at 11:28:13PM +0300, Samium Gromoff wrote:
> > Author: Samium Gromoff <[EMAIL PROTECTED]>
> > Date: Tue Jan 23 22:31:13 2007 +0300
> >
> > Define the ELF binary header flag EF_AS_NO_RANDOM
> >
> > EF_AS_NO_RANDOM should mean that the binary requests to not apply
> > randomisation to address spaces of its processes.
> >
> > diff --git a/include/linux/elf.h b/include/linux/elf.h
> > index 60713e6..58ebb47 100644
> > --- a/include/linux/elf.h
> > +++ b/include/linux/elf.h
> > @@ -172,6 +172,8 @@ typedef struct elf64_sym {
> >
> > #define EI_NIDENT 16
> >
> > +#define EF_AS_NO_RANDOM 0x1/* do not randomise the address space */
> > +
>
> You can't make up EF_* flags this way, they are arch specific, the LSB bit
> (but many others too) are already used on many architectures.
> E.g.:
> elf/mt.h:#define EF_MT_CPU_MRISC 0x0001 /* default */
> elf/sparc.h:#define EF_SPARCV9_PSO0x1 /* partial
> store ordering */
> elf/bfin.h:#define EF_BFIN_PIC0x0001 /* -fpic */
> elf/alpha.h:#define EF_ALPHA_32BIT0x0001
> elf/mips.h:#define EF_MIPS_NOREORDER 0x0001
> elf/m68k.h:#define EF_M68K_CF_ISA_A_NODIV 0x01 /* ISA A except for div */
> elf/sh.h:#define EF_SH1 1
> elf/arm.h:#define EF_ARM_RELEXEC 0x01
> elf/cris.h:#define EF_CRIS_UNDERSCORE 0x0001
> elf/ia64.h:#define EF_IA_64_TRAPNIL (1 << 0) /* Trap NIL pointer
> dereferences. */
> elf/vax.h:#define EF_VAX_NONPIC 0x0001 /* Object contains
> non-PIC code */
> elf/iq2000.h:#define EF_IQ2000_CPU_IQ2000 0x0001 /* default */
> elf/frv.h:#define EF_FRV_GPR_32 0x0001 /* -mgpr-32 */
> to name just a few.
Should we introduce per-arch asm/elf.h files to hold the relevant flag
definitions then?
> Jakub
regards, Samium Gromoff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Make the EF_AS_NO_RANDOM e_flag bit disable PF_RANDOMIZE
Author: Samium Gromoff <[EMAIL PROTECTED]> Date: Tue Jan 23 23:12:16 2007 +0300 load_elf_binary: do not set PF_RANDOMIZE if the ELF file has EF_AS_NO_RANDOM s et diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index 7cb2872..007dedd 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -780,7 +780,8 @@ static int load_elf_binary(struct linux_binprm *bprm, struct p t_regs *regs) if (elf_read_implies_exec(loc->elf_ex, executable_stack)) current->personality |= READ_IMPLIES_EXEC; - if (!(current->personality & ADDR_NO_RANDOMIZE) && randomize_va_space) + if (!(current->personality & ADDR_NO_RANDOMIZE) && + !(loc->elf_ex.e_flags & EF_AS_NO_RANDOM) && randomize_va_space) current->flags |= PF_RANDOMIZE; arch_pick_mmap_layout(current->mm); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit
Author: Samium Gromoff <[EMAIL PROTECTED]>
Date: Tue Jan 23 22:31:13 2007 +0300
Define the ELF binary header flag EF_AS_NO_RANDOM
EF_AS_NO_RANDOM should mean that the binary requests to not apply
randomisation to address spaces of its processes.
diff --git a/include/linux/elf.h b/include/linux/elf.h
index 60713e6..58ebb47 100644
--- a/include/linux/elf.h
+++ b/include/linux/elf.h
@@ -172,6 +172,8 @@ typedef struct elf64_sym {
#define EI_NIDENT 16
+#define EF_AS_NO_RANDOM 0x1/* do not randomise the address space */
+
typedef struct elf32_hdr{
unsigned chare_ident[EI_NIDENT];
Elf32_Half e_type;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] Mechanism to turn of ASR on a per-ELF binary basis
These patches allow the binaries which absolutely require that their address space layout to be unaffected by address space randomisation to specify that in their ELF header. The first part defines the ELF header flag, the second implements the corresponding part of the interpreter functionality. regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
At Tue, 23 Jan 2007 08:48:07 +, Pavel Machek wrote: > > Are you saying that the usefulness of AS randomisation is > > overall exceeding that of MAP_FIXED, and the latter should be > > abolished? > > MAP_FIXED still works. You just have to be more careful where you map. No amount of carefulness will prevent vendors stick arbitrarily damaging values of stack and mmap base randomisation, severely reducing the usefullness of MAP_FIXED. And they actively take this freedom -- Arjan must know this first-hand. > > > > the only way to achieve this i see, is to directly setuid root > > > > the lisp system executable itself -- because the lisp code > > > > is read, compiled and executed in the process of the lisp > > > > system executable. > > > > > > If that's the only way you can see to do it, maybe you should think a > > > bit harder before making kernel hacks to do something. > > > > I want equal grounds for platforms, that`s all. > > Well, noone ever said all languages are equal. You have crappy lisp > interpreters, and you want to break kernel because you are too lazy to > fix them, and insist they must do suid in any way you choose. We won't > break kernel because lisp is misdesigned. SBCL is the most actively developed open source Common Lisp implementation, which has an optimising native compiler built in, so it is not an interpreter, and is, most certainly, not crappy. Speaking on the matter, how would you regard a patch which enhances the ELF loader with interpretation of an x86-specific e_flags bit which would mean a mandatory AS randomisation disable? this has the following properties: 1. cannot serve as a vehicle for exploitation for binaries unmarked with this flag 2. serve the application deployment cause -- abolish the need for application-specific system tweaks 3. remove the need for the ugly self-reexecution tweak people needing an absolutely unadulterated memory map have to resort to /now/, even in a non-setuid case > Pavel P.S.: Please, shrug off that C-esque center-of-the-world attitude, the fact there are thousand times as many C programmers does not automatically mean there is a free-for-all no-questions-asked licence to raise the implementation complexity bar for other languages. regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] Mechanism to turn of ASR on a per-ELF binary basis
These patches allow the binaries which absolutely require that their address space layout to be unaffected by address space randomisation to specify that in their ELF header. The first part defines the ELF header flag, the second implements the corresponding part of the interpreter functionality. regards, Samium Gromoff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit
Author: Samium Gromoff [EMAIL PROTECTED]
Date: Tue Jan 23 22:31:13 2007 +0300
Define the ELF binary header flag EF_AS_NO_RANDOM
EF_AS_NO_RANDOM should mean that the binary requests to not apply
randomisation to address spaces of its processes.
diff --git a/include/linux/elf.h b/include/linux/elf.h
index 60713e6..58ebb47 100644
--- a/include/linux/elf.h
+++ b/include/linux/elf.h
@@ -172,6 +172,8 @@ typedef struct elf64_sym {
#define EI_NIDENT 16
+#define EF_AS_NO_RANDOM 0x1/* do not randomise the address space */
+
typedef struct elf32_hdr{
unsigned chare_ident[EI_NIDENT];
Elf32_Half e_type;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Make the EF_AS_NO_RANDOM e_flag bit disable PF_RANDOMIZE
Author: Samium Gromoff [EMAIL PROTECTED] Date: Tue Jan 23 23:12:16 2007 +0300 load_elf_binary: do not set PF_RANDOMIZE if the ELF file has EF_AS_NO_RANDOM s et diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index 7cb2872..007dedd 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -780,7 +780,8 @@ static int load_elf_binary(struct linux_binprm *bprm, struct p t_regs *regs) if (elf_read_implies_exec(loc-elf_ex, executable_stack)) current-personality |= READ_IMPLIES_EXEC; - if (!(current-personality ADDR_NO_RANDOMIZE) randomize_va_space) + if (!(current-personality ADDR_NO_RANDOMIZE) + !(loc-elf_ex.e_flags EF_AS_NO_RANDOM) randomize_va_space) current-flags |= PF_RANDOMIZE; arch_pick_mmap_layout(current-mm); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit
At Tue, 23 Jan 2007 15:50:18 -0500,
Jakub Jelinek wrote:
On Tue, Jan 23, 2007 at 11:28:13PM +0300, Samium Gromoff wrote:
Author: Samium Gromoff [EMAIL PROTECTED]
Date: Tue Jan 23 22:31:13 2007 +0300
Define the ELF binary header flag EF_AS_NO_RANDOM
EF_AS_NO_RANDOM should mean that the binary requests to not apply
randomisation to address spaces of its processes.
diff --git a/include/linux/elf.h b/include/linux/elf.h
index 60713e6..58ebb47 100644
--- a/include/linux/elf.h
+++ b/include/linux/elf.h
@@ -172,6 +172,8 @@ typedef struct elf64_sym {
#define EI_NIDENT 16
+#define EF_AS_NO_RANDOM 0x1/* do not randomise the address space */
+
You can't make up EF_* flags this way, they are arch specific, the LSB bit
(but many others too) are already used on many architectures.
E.g.:
elf/mt.h:#define EF_MT_CPU_MRISC 0x0001 /* default */
elf/sparc.h:#define EF_SPARCV9_PSO0x1 /* partial
store ordering */
elf/bfin.h:#define EF_BFIN_PIC0x0001 /* -fpic */
elf/alpha.h:#define EF_ALPHA_32BIT0x0001
elf/mips.h:#define EF_MIPS_NOREORDER 0x0001
elf/m68k.h:#define EF_M68K_CF_ISA_A_NODIV 0x01 /* ISA A except for div */
elf/sh.h:#define EF_SH1 1
elf/arm.h:#define EF_ARM_RELEXEC 0x01
elf/cris.h:#define EF_CRIS_UNDERSCORE 0x0001
elf/ia64.h:#define EF_IA_64_TRAPNIL (1 0) /* Trap NIL pointer
dereferences. */
elf/vax.h:#define EF_VAX_NONPIC 0x0001 /* Object contains
non-PIC code */
elf/iq2000.h:#define EF_IQ2000_CPU_IQ2000 0x0001 /* default */
elf/frv.h:#define EF_FRV_GPR_32 0x0001 /* -mgpr-32 */
to name just a few.
Should we introduce per-arch asm/elf.h files to hold the relevant flag
definitions then?
Jakub
regards, Samium Gromoff
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit
At Tue, 23 Jan 2007 16:16:12 -0500, Jakub Jelinek wrote: On Wed, Jan 24, 2007 at 12:06:45AM +0300, Samium Gromoff wrote: Should we introduce per-arch asm/elf.h files to hold the relevant flag definitions then? On some architectures there are no bits left. On others you'd need to go through whomever maintains the relevant psABI to get a bit officially allocated. Really, it is very bad idea to use e_flags for this. Currently arch_align_stack() and mmap_base() perform randomisation only on x86 and x86_64, so it is only two architectures anyway... If all you care about is running setuid LISP programs, you'd much better put your energy into fixing the buggy ELF dumper in it. Jakub regards, Samium Gromoff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit
At Tue, 23 Jan 2007 16:16:12 -0500, Jakub Jelinek wrote: On Wed, Jan 24, 2007 at 12:06:45AM +0300, Samium Gromoff wrote: Should we introduce per-arch asm/elf.h files to hold the relevant flag definitions then? On some architectures there are no bits left. On others you'd need to go through whomever maintains the relevant psABI to get a bit officially allocated. Really, it is very bad idea to use e_flags for this. How does one find the relevant maintainers? Even just the specs are harder to find in the authoritative location, given the OSDL and FSG merge: the psabi documents at http://www.linux-foundation.org/spec/refspecs/ all 404... If all you care about is running setuid LISP programs, you'd much better put your energy into fixing the buggy ELF dumper in it. Jakub regards, Samium Gromoff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
At Tue, 23 Jan 2007 08:48:07 +, Pavel Machek wrote: Are you saying that the usefulness of AS randomisation is overall exceeding that of MAP_FIXED, and the latter should be abolished? MAP_FIXED still works. You just have to be more careful where you map. No amount of carefulness will prevent vendors stick arbitrarily damaging values of stack and mmap base randomisation, severely reducing the usefullness of MAP_FIXED. And they actively take this freedom -- Arjan must know this first-hand. the only way to achieve this i see, is to directly setuid root the lisp system executable itself -- because the lisp code is read, compiled and executed in the process of the lisp system executable. If that's the only way you can see to do it, maybe you should think a bit harder before making kernel hacks to do something. I want equal grounds for platforms, that`s all. Well, noone ever said all languages are equal. You have crappy lisp interpreters, and you want to break kernel because you are too lazy to fix them, and insist they must do suid in any way you choose. We won't break kernel because lisp is misdesigned. SBCL is the most actively developed open source Common Lisp implementation, which has an optimising native compiler built in, so it is not an interpreter, and is, most certainly, not crappy. Speaking on the matter, how would you regard a patch which enhances the ELF loader with interpretation of an x86-specific e_flags bit which would mean a mandatory AS randomisation disable? this has the following properties: 1. cannot serve as a vehicle for exploitation for binaries unmarked with this flag 2. serve the application deployment cause -- abolish the need for application-specific system tweaks 3. remove the need for the ugly self-reexecution tweak people needing an absolutely unadulterated memory map have to resort to /now/, even in a non-setuid case Pavel P.S.: Please, shrug off that C-esque center-of-the-world attitude, the fact there are thousand times as many C programmers does not automatically mean there is a free-for-all no-questions-asked licence to raise the implementation complexity bar for other languages. regards, Samium Gromoff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
At Mon, 22 Jan 2007 01:35:46 +0100, Arjan van de Ven wrote: > > > > the core of the problem are the cores which are customarily > > dumped by lisps during the environment generation (or modification) stage, > > and then mapped back, every time the environment is invoked. > > > > > at the current step of evolution, those core files are not relocatable > > in certain natively compiling lisp systems. > > nor will they work if the sysadmin applies a security update and glibc > or another library changes one page in size. Or changes the stack rlimit > or .. or .. Now, i figured out, there is a certain reasonable safety gap which works for people, because the libraries depended on are well known. What happens with AS randomisation, is that the variance is simply too large. But what is more important, is that vendors do modifications which change the amount of randomisation, which means that potentially no MAP_FIXED is safe, generally. Yes, there is uncertainty in both cases -- library variance or AS randomisation, but the latter arguably crosses a practical manageability boundary. > -- > if you want to mail me at work (you don't), use arjan (at) linux.intel.com > Test the interaction between Linux and your BIOS via > http://www.linuxfirmwarekit.org regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
At Mon, 22 Jan 2007 10:20:21 -0500, [EMAIL PROTECTED] wrote: > On Mon, 22 Jan 2007 02:23:30 +0300, Samium Gromoff said: > > > > not "core-dumps" but "core files", in the lispspeak, but anyway. > > > > the reason is trivial -- if i can write programs enjoying setuid > > privileges in C, i want to be able to do the same in Lisp. > > Go read up on how the XEmacs crew designed their "portable dumper", > specifically to get around a lot of these sorts of problems because the > old Emacs 'unexec' code was incredibly fragile. I should take the freedom to respond in your manner :-) Are you saying that the usefulness of AS randomisation is overall exceeding that of MAP_FIXED, and the latter should be abolished? Did we silently enter an era where support for buggy software is more important than a basic mmap feature? > > the only way to achieve this i see, is to directly setuid root > > the lisp system executable itself -- because the lisp code > > is read, compiled and executed in the process of the lisp > > system executable. > > If that's the only way you can see to do it, maybe you should think a > bit harder before making kernel hacks to do something. I want equal grounds for platforms, that`s all. regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
At Mon, 22 Jan 2007 10:20:21 -0500, [EMAIL PROTECTED] wrote: On Mon, 22 Jan 2007 02:23:30 +0300, Samium Gromoff said: not core-dumps but core files, in the lispspeak, but anyway. the reason is trivial -- if i can write programs enjoying setuid privileges in C, i want to be able to do the same in Lisp. Go read up on how the XEmacs crew designed their portable dumper, specifically to get around a lot of these sorts of problems because the old Emacs 'unexec' code was incredibly fragile. I should take the freedom to respond in your manner :-) Are you saying that the usefulness of AS randomisation is overall exceeding that of MAP_FIXED, and the latter should be abolished? Did we silently enter an era where support for buggy software is more important than a basic mmap feature? the only way to achieve this i see, is to directly setuid root the lisp system executable itself -- because the lisp code is read, compiled and executed in the process of the lisp system executable. If that's the only way you can see to do it, maybe you should think a bit harder before making kernel hacks to do something. I want equal grounds for platforms, that`s all. regards, Samium Gromoff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
At Mon, 22 Jan 2007 01:35:46 +0100, Arjan van de Ven wrote: the core of the problem are the cores which are customarily dumped by lisps during the environment generation (or modification) stage, and then mapped back, every time the environment is invoked. at the current step of evolution, those core files are not relocatable in certain natively compiling lisp systems. nor will they work if the sysadmin applies a security update and glibc or another library changes one page in size. Or changes the stack rlimit or .. or .. Now, i figured out, there is a certain reasonable safety gap which works for people, because the libraries depended on are well known. What happens with AS randomisation, is that the variance is simply too large. But what is more important, is that vendors do modifications which change the amount of randomisation, which means that potentially no MAP_FIXED is safe, generally. Yes, there is uncertainty in both cases -- library variance or AS randomisation, but the latter arguably crosses a practical manageability boundary. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org regards, Samium Gromoff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
At Sun, 21 Jan 2007 19:36:27 -0500, Kyle Moffett wrote: > > On Jan 21, 2007, at 18:34:56, David Wagner wrote: > > [1] In comparison, suidperl was designed to be installed setuid- > > root, and it takes special precautions to be safe in this usage. > > (And even it has had some security vulnerabilities, despite its > > best efforts, which illustrates how tricky this business can be.) > > Setting the setuid-root bit on a large complex interpreter that > > wasn't designed to be setuid-root seems like a pretty dubious > > proposition to me. > > Well, there's also the fact that Linux does *NOT* need suidperl, as > it has proper secure support for suid pound-bang scripts anyways. > The only reason for suidperl in the first place was broken operating > systems which had a race condition between the operating system > checking the suid bits and reading the '#! /usr/bin/perl' line in the > file, and the interpreter getting executed and opening a different > file (think symlink redirection attacks). I believe Linux jumps > through some special hoops to ensure that can't happen. Uh, this does not work, unfortunately in the Lisp case. Lisp environments can produce standalone executables, which are 1. supposed to be runnable like a usual binary, without any additions 2. will suffer from the very same problem, as it merely is a runtime bundled with the core file (and the core file is unrelocatable) > Kyle Moffett regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
At Mon, 22 Jan 2007 01:35:46 +0100, Arjan van de Ven wrote: > > the core of the problem are the cores which are customarily > > dumped by lisps during the environment generation (or modification) stage, > > and then mapped back, every time the environment is invoked. > > > > > at the current step of evolution, those core files are not relocatable > > in certain natively compiling lisp systems. > > nor will they work if the sysadmin applies a security update and glibc > or another library changes one page in size. Or changes the stack rlimit > or .. or .. At this point i should just step down and declare incompetence -- SBCL works around shlib size variance, somehow, and /yet/ the whole turn-off-AS-randomisation-and-reexec-self thing is still present in the source, for some reason. I should let more competent people (read, the actual SBCL developers) take the way from now... (I could have digged the source myself, but it is way too late today. However, if nobody from the development team answers by tomorrow`s evening (gmt+3), i should see into the thing for myself). > -- > if you want to mail me at work (you don't), use arjan (at) linux.intel.com > Test the interaction between Linux and your BIOS via > http://www.linuxfirmwarekit.org regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
David Wagner wrote: > Samium Gromoff wrote: > >[...] directly setuid root the lisp system executable itself [...] > > Like I said, that sounds like a bad idea to me. Sounds like a recipe for > privilege escalation vulnerabilities. Was the lisp system executable > really implemented to be secure even when you make it setuid root? > Setting the setuid-root bit on programs that didn't expect to be > setuid-root is generally not a very safe thing to do. [1] 1. Unsafe setuid programs have been written, and they doubtlessly will continue to be written. 2. Lisp systems are written by extremely competent people. (who make mistakes nonetheless, but still..) 3. I think that the ability to choose whether or not to shoot oneself in the foot is an important freedom. 4. The whole issue is a little bit unfair, because the UNIX world is inherently C-centric -- everything outside the C niche does not, indeed, fit flawlessly in the picture.. This is where the "if you want to write system software, do it in C" model comes from. 5. If a killer use-case is needed, an X server might do -- these need root privileges for a certain period. What if i decide that i want to write one in Lisp? > The more I hear, the more unconvinced I am by this use case. > > If you don't care about the security issues created by (mis)using the lisp > interpreter in this way, then like I suggested before, you can always ^^^ make that a compiler -- these days, probably, there are more native-bytecode-generating lisp compilers than interpreters. > write a tiny setuid-root wrapper program that turns off address space > randomization and exec()s the lisp system executable, and leave the lisp > system executable non-setuid and don't touch the code in the Linux kernel. > That strikes me as a better solution: those who don't mind the security > risks can take all the risks they want, without forcing others to take > unwanted and unnecessary risks. This might sound as a reasonable solution. Although it places a certain burden, which has to be considered... I should see what the SBCL people will say about that. > It's not that I'm wedded to address space randomization of setuid > programs, or that I think it would be a disaster if this patch were > accepted. Local privilege escalation attacks aren't the end of the world; > in all honesty, they're pretty much irrelevant to many or most users. > It's just that the arguments I'm hearing advanced in support of this > change seem dubious, and the change does eliminate one of the defenses > against a certain (narrow) class of attacks. > > > [1] In comparison, suidperl was designed to be installed setuid-root, > and it takes special precautions to be safe in this usage. (And even it > has had some security vulnerabilities, despite its best efforts, which > illustrates how tricky this business can be.) Setting the setuid-root > bit on a large complex interpreter that wasn't designed to be setuid-root > seems like a pretty dubious proposition to me. Compiler, not interpreter, careful with the insults :-) regards, Samium Gromoff P.S. please cc me, as i am not subscribed to the list... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
David Wagner wrote: > Samium Gromoff wrote: > >the core of the problem are the cores which are customarily > >dumped by lisps during the environment generation (or modification) stage, > >and then mapped back, every time the environment is invoked. > > > >at the current step of evolution, those core files are not relocatable > >in certain natively compiling lisp systems. > > > >in an even smaller subset of them, these cores are placed after > >the shared libraries and the executable. > > > >which obviously breaks when the latter are placed unpredictably. > >(yes, i know, currently mmap_base() varies over a 1MB range, but who > >says it will last indefinitely -- probably one day these people > >from full-disclosure will prevail and it will become, like, 256MB ;-) > > > >so, what do you propose? > > The obvious solution is: Don't make them setuid root. > Then this issue disappears. > > If there is some strong reason why they need to be setuid root, then > you'll need to explain that reason and your requirements in more detail. > But, based on your explanation so far, I have serious doubts about > whether it is a good idea to make such core-dumps setuid root in the > first place. not "core-dumps" but "core files", in the lispspeak, but anyway. the reason is trivial -- if i can write programs enjoying setuid privileges in C, i want to be able to do the same in Lisp. the only way to achieve this i see, is to directly setuid root the lisp system executable itself -- because the lisp code is read, compiled and executed in the process of the lisp system executable. there is such a thing as suid-perl -- for precise same reasons. regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[no subject]
David Wagner wrote: > Samium Gromoff wrote: > >the core of the problem are the cores which are customarily > >dumped by lisps during the environment generation (or modification) stage, > >and then mapped back, every time the environment is invoked. > > > >at the current step of evolution, those core files are not relocatable > >in certain natively compiling lisp systems. > > > >in an even smaller subset of them, these cores are placed after > >the shared libraries and the executable. > > > >which obviously breaks when the latter are placed unpredictably. > >(yes, i know, currently mmap_base() varies over a 1MB range, but who > >says it will last indefinitely -- probably one day these people > >from full-disclosure will prevail and it will become, like, 256MB ;-) > > > >so, what do you propose? > > The obvious solution is: Don't make them setuid root. > Then this issue disappears. > > If there is some strong reason why they need to be setuid root, then > you'll need to explain that reason and your requirements in more detail. > But, based on your explanation so far, I have serious doubts about > whether it is a good idea to make such core-dumps setuid root in the > first place. not "core-dumps" but "core files", in the lispspeak, but anyway. the reason is trivial -- if i can write programs enjoying setuid privileges in C, i want to be able to do the same in Lisp. the only way to achieve this i see, is to directly setuid root the lisp system executable itself -- because the lisp code is read, compiled and executed in the process of the lisp system executable. there is such a thing as suid-perl -- for precise same reasons. regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
At Sun, 21 Jan 2007 03:16:04 +0100, Arjan van de Ven wrote: > > On Sat, 2007-01-20 at 17:37 +0300, Samium Gromoff wrote: > > This patch removes the dropping of ADDR_NO_RANDOMIZE upon execution of > > setuid > > binaries. > > > > Why? The answer consists of two parts: > > > > Firstly, there are valid applications which need an unadulterated memory > > map. > > Some of those which do their memory management, like lisp systems (like > > SBCL). > > They try to achieve this by setting ADDR_NO_RANDOMIZE and reexecuting > > themselves. > > this is a ... funny way of achieving this > > if an application for some reason wants some fixed address for a piece > of memory there are other ways to do that (but to some degree all > apps that can't take randomization broken; for example a glibc upgrade > on a system will also move the address space around by virtue of being > bigger or smaller etc etc) the core of the problem are the cores which are customarily dumped by lisps during the environment generation (or modification) stage, and then mapped back, every time the environment is invoked. at the current step of evolution, those core files are not relocatable in certain natively compiling lisp systems. in an even smaller subset of them, these cores are placed after the shared libraries and the executable. which obviously breaks when the latter are placed unpredictably. (yes, i know, currently mmap_base() varies over a 1MB range, but who says it will last indefinitely -- probably one day these people from full-disclosure will prevail and it will become, like, 256MB ;-) so, what do you propose? regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
At Sun, 21 Jan 2007 03:16:04 +0100, Arjan van de Ven wrote: > On Sat, 2007-01-20 at 17:37 +0300, Samium Gromoff wrote: > > This patch removes the dropping of ADDR_NO_RANDOMIZE upon execution of > > setuid > > binaries. > > > > Why? The answer consists of two parts: > > > > Firstly, there are valid applications which need an unadulterated memory > > map. > > Some of those which do their memory management, like lisp systems (like > > SBCL). > > They try to achieve this by setting ADDR_NO_RANDOMIZE and reexecuting > > themselves. > > this is a ... funny way of achieving this > > if an application for some reason wants some fixed address for a piece > of memory there are other ways to do that (but to some degree all > apps that can't take randomization broken; for example a glibc upgrade > on a system will also move the address space around by virtue of being > bigger or smaller etc etc) > > [1]. See the excellent, 'Hackers Hut' by Andries Brouwer, which describes > > how AS randomisation can be got around by the means of linux-gate.so.1 > > got a URL to this? If this is exploiting the fact that the vdso is at a > fixed spot... it's no longer the case since quite a while. hmm, it seems to rely on that, yes: http://www.win.tue.nl/~aeb/linux/hhh/hh-9.html#ss9.6 > -- > if you want to mail me at work (you don't), use arjan (at) linux.intel.com > Test the interaction between Linux and your BIOS via > http://www.linuxfirmwarekit.org regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
At Sun, 21 Jan 2007 03:16:04 +0100, Arjan van de Ven wrote: On Sat, 2007-01-20 at 17:37 +0300, Samium Gromoff wrote: This patch removes the dropping of ADDR_NO_RANDOMIZE upon execution of setuid binaries. Why? The answer consists of two parts: Firstly, there are valid applications which need an unadulterated memory map. Some of those which do their memory management, like lisp systems (like SBCL). They try to achieve this by setting ADDR_NO_RANDOMIZE and reexecuting themselves. this is a ... funny way of achieving this if an application for some reason wants some fixed address for a piece of memory there are other ways to do that (but to some degree all apps that can't take randomization broken; for example a glibc upgrade on a system will also move the address space around by virtue of being bigger or smaller etc etc) [1]. See the excellent, 'Hackers Hut' by Andries Brouwer, which describes how AS randomisation can be got around by the means of linux-gate.so.1 got a URL to this? If this is exploiting the fact that the vdso is at a fixed spot... it's no longer the case since quite a while. hmm, it seems to rely on that, yes: http://www.win.tue.nl/~aeb/linux/hhh/hh-9.html#ss9.6 -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org regards, Samium Gromoff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
At Sun, 21 Jan 2007 03:16:04 +0100, Arjan van de Ven wrote: On Sat, 2007-01-20 at 17:37 +0300, Samium Gromoff wrote: This patch removes the dropping of ADDR_NO_RANDOMIZE upon execution of setuid binaries. Why? The answer consists of two parts: Firstly, there are valid applications which need an unadulterated memory map. Some of those which do their memory management, like lisp systems (like SBCL). They try to achieve this by setting ADDR_NO_RANDOMIZE and reexecuting themselves. this is a ... funny way of achieving this if an application for some reason wants some fixed address for a piece of memory there are other ways to do that (but to some degree all apps that can't take randomization broken; for example a glibc upgrade on a system will also move the address space around by virtue of being bigger or smaller etc etc) the core of the problem are the cores which are customarily dumped by lisps during the environment generation (or modification) stage, and then mapped back, every time the environment is invoked. at the current step of evolution, those core files are not relocatable in certain natively compiling lisp systems. in an even smaller subset of them, these cores are placed after the shared libraries and the executable. which obviously breaks when the latter are placed unpredictably. (yes, i know, currently mmap_base() varies over a 1MB range, but who says it will last indefinitely -- probably one day these people from full-disclosure will prevail and it will become, like, 256MB ;-) so, what do you propose? regards, Samium Gromoff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[no subject]
David Wagner wrote: Samium Gromoff wrote: the core of the problem are the cores which are customarily dumped by lisps during the environment generation (or modification) stage, and then mapped back, every time the environment is invoked. at the current step of evolution, those core files are not relocatable in certain natively compiling lisp systems. in an even smaller subset of them, these cores are placed after the shared libraries and the executable. which obviously breaks when the latter are placed unpredictably. (yes, i know, currently mmap_base() varies over a 1MB range, but who says it will last indefinitely -- probably one day these people from full-disclosure will prevail and it will become, like, 256MB ;-) so, what do you propose? The obvious solution is: Don't make them setuid root. Then this issue disappears. If there is some strong reason why they need to be setuid root, then you'll need to explain that reason and your requirements in more detail. But, based on your explanation so far, I have serious doubts about whether it is a good idea to make such core-dumps setuid root in the first place. not core-dumps but core files, in the lispspeak, but anyway. the reason is trivial -- if i can write programs enjoying setuid privileges in C, i want to be able to do the same in Lisp. the only way to achieve this i see, is to directly setuid root the lisp system executable itself -- because the lisp code is read, compiled and executed in the process of the lisp system executable. there is such a thing as suid-perl -- for precise same reasons. regards, Samium Gromoff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
David Wagner wrote: Samium Gromoff wrote: the core of the problem are the cores which are customarily dumped by lisps during the environment generation (or modification) stage, and then mapped back, every time the environment is invoked. at the current step of evolution, those core files are not relocatable in certain natively compiling lisp systems. in an even smaller subset of them, these cores are placed after the shared libraries and the executable. which obviously breaks when the latter are placed unpredictably. (yes, i know, currently mmap_base() varies over a 1MB range, but who says it will last indefinitely -- probably one day these people from full-disclosure will prevail and it will become, like, 256MB ;-) so, what do you propose? The obvious solution is: Don't make them setuid root. Then this issue disappears. If there is some strong reason why they need to be setuid root, then you'll need to explain that reason and your requirements in more detail. But, based on your explanation so far, I have serious doubts about whether it is a good idea to make such core-dumps setuid root in the first place. not core-dumps but core files, in the lispspeak, but anyway. the reason is trivial -- if i can write programs enjoying setuid privileges in C, i want to be able to do the same in Lisp. the only way to achieve this i see, is to directly setuid root the lisp system executable itself -- because the lisp code is read, compiled and executed in the process of the lisp system executable. there is such a thing as suid-perl -- for precise same reasons. regards, Samium Gromoff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
David Wagner wrote: Samium Gromoff wrote: [...] directly setuid root the lisp system executable itself [...] Like I said, that sounds like a bad idea to me. Sounds like a recipe for privilege escalation vulnerabilities. Was the lisp system executable really implemented to be secure even when you make it setuid root? Setting the setuid-root bit on programs that didn't expect to be setuid-root is generally not a very safe thing to do. [1] 1. Unsafe setuid programs have been written, and they doubtlessly will continue to be written. 2. Lisp systems are written by extremely competent people. (who make mistakes nonetheless, but still..) 3. I think that the ability to choose whether or not to shoot oneself in the foot is an important freedom. 4. The whole issue is a little bit unfair, because the UNIX world is inherently C-centric -- everything outside the C niche does not, indeed, fit flawlessly in the picture.. This is where the if you want to write system software, do it in C model comes from. 5. If a killer use-case is needed, an X server might do -- these need root privileges for a certain period. What if i decide that i want to write one in Lisp? The more I hear, the more unconvinced I am by this use case. If you don't care about the security issues created by (mis)using the lisp interpreter in this way, then like I suggested before, you can always ^^^ make that a compiler -- these days, probably, there are more native-bytecode-generating lisp compilers than interpreters. write a tiny setuid-root wrapper program that turns off address space randomization and exec()s the lisp system executable, and leave the lisp system executable non-setuid and don't touch the code in the Linux kernel. That strikes me as a better solution: those who don't mind the security risks can take all the risks they want, without forcing others to take unwanted and unnecessary risks. This might sound as a reasonable solution. Although it places a certain burden, which has to be considered... I should see what the SBCL people will say about that. It's not that I'm wedded to address space randomization of setuid programs, or that I think it would be a disaster if this patch were accepted. Local privilege escalation attacks aren't the end of the world; in all honesty, they're pretty much irrelevant to many or most users. It's just that the arguments I'm hearing advanced in support of this change seem dubious, and the change does eliminate one of the defenses against a certain (narrow) class of attacks. [1] In comparison, suidperl was designed to be installed setuid-root, and it takes special precautions to be safe in this usage. (And even it has had some security vulnerabilities, despite its best efforts, which illustrates how tricky this business can be.) Setting the setuid-root bit on a large complex interpreter that wasn't designed to be setuid-root seems like a pretty dubious proposition to me. Compiler, not interpreter, careful with the insults :-) regards, Samium Gromoff P.S. please cc me, as i am not subscribed to the list... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
At Mon, 22 Jan 2007 01:35:46 +0100, Arjan van de Ven wrote: the core of the problem are the cores which are customarily dumped by lisps during the environment generation (or modification) stage, and then mapped back, every time the environment is invoked. at the current step of evolution, those core files are not relocatable in certain natively compiling lisp systems. nor will they work if the sysadmin applies a security update and glibc or another library changes one page in size. Or changes the stack rlimit or .. or .. At this point i should just step down and declare incompetence -- SBCL works around shlib size variance, somehow, and /yet/ the whole turn-off-AS-randomisation-and-reexec-self thing is still present in the source, for some reason. I should let more competent people (read, the actual SBCL developers) take the way from now... (I could have digged the source myself, but it is way too late today. However, if nobody from the development team answers by tomorrow`s evening (gmt+3), i should see into the thing for myself). -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org regards, Samium Gromoff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
At Sun, 21 Jan 2007 19:36:27 -0500, Kyle Moffett wrote: On Jan 21, 2007, at 18:34:56, David Wagner wrote: [1] In comparison, suidperl was designed to be installed setuid- root, and it takes special precautions to be safe in this usage. (And even it has had some security vulnerabilities, despite its best efforts, which illustrates how tricky this business can be.) Setting the setuid-root bit on a large complex interpreter that wasn't designed to be setuid-root seems like a pretty dubious proposition to me. Well, there's also the fact that Linux does *NOT* need suidperl, as it has proper secure support for suid pound-bang scripts anyways. The only reason for suidperl in the first place was broken operating systems which had a race condition between the operating system checking the suid bits and reading the '#! /usr/bin/perl' line in the file, and the interpreter getting executed and opening a different file (think symlink redirection attacks). I believe Linux jumps through some special hoops to ensure that can't happen. Uh, this does not work, unfortunately in the Lisp case. Lisp environments can produce standalone executables, which are 1. supposed to be runnable like a usual binary, without any additions 2. will suffer from the very same problem, as it merely is a runtime bundled with the core file (and the core file is unrelocatable) Kyle Moffett regards, Samium Gromoff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
At Sat, 20 Jan 2007 17:37:22 +0300, Samium Gromoff wrote: [snip] > So, here we have a buffer-overflow protection technique, which does not > actually protect against buffer overflows[1], breaking valid applications. > > I suggest getting rid of it. i botched it slightly: --- linux/include/linux/personality.h 2007-01-20 17:31:01.0 +0300 +++ linux-sane/include/linux/personality.h 2007-01-20 17:32:50.0 +0300 @@ -40,7 +40,7 @@ * Security-relevant compatibility flags that must be * cleared upon setuid or setgid exec: */ -#define PER_CLEAR_ON_SETID (READ_IMPLIES_EXEC|ADDR_NO_RANDOMIZE) +#define PER_CLEAR_ON_SETID (READ_IMPLIES_EXEC) Signed-off-by: Samium Gromoff <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Undo some of the pseudo-security madness
This patch removes the dropping of ADDR_NO_RANDOMIZE upon execution of setuid binaries. Why? The answer consists of two parts: Firstly, there are valid applications which need an unadulterated memory map. Some of those which do their memory management, like lisp systems (like SBCL). They try to achieve this by setting ADDR_NO_RANDOMIZE and reexecuting themselves. Secondly, there also are valid reasons to want those applications to be setuid root. Like poking hardware. So, here we have a buffer-overflow protection technique, which does not actually protect against buffer overflows[1], breaking valid applications. I suggest getting rid of it. --- include/linux/personality.h 2007-01-20 17:31:01.0 +0300 +++ include/linux-sane/personality.h2007-01-20 17:32:50.0 +0300 @@ -40,7 +40,7 @@ * Security-relevant compatibility flags that must be * cleared upon setuid or setgid exec: */ -#define PER_CLEAR_ON_SETID (READ_IMPLIES_EXEC|ADDR_NO_RANDOMIZE) +#define PER_CLEAR_ON_SETID (READ_IMPLIES_EXEC) /* * Personality types. Signed-off-by: Samium Gromoff <[EMAIL PROTECTED]> [1]. See the excellent, 'Hackers Hut' by Andries Brouwer, which describes how AS randomisation can be got around by the means of linux-gate.so.1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Undo some of the pseudo-security madness
This patch removes the dropping of ADDR_NO_RANDOMIZE upon execution of setuid binaries. Why? The answer consists of two parts: Firstly, there are valid applications which need an unadulterated memory map. Some of those which do their memory management, like lisp systems (like SBCL). They try to achieve this by setting ADDR_NO_RANDOMIZE and reexecuting themselves. Secondly, there also are valid reasons to want those applications to be setuid root. Like poking hardware. So, here we have a buffer-overflow protection technique, which does not actually protect against buffer overflows[1], breaking valid applications. I suggest getting rid of it. --- include/linux/personality.h 2007-01-20 17:31:01.0 +0300 +++ include/linux-sane/personality.h2007-01-20 17:32:50.0 +0300 @@ -40,7 +40,7 @@ * Security-relevant compatibility flags that must be * cleared upon setuid or setgid exec: */ -#define PER_CLEAR_ON_SETID (READ_IMPLIES_EXEC|ADDR_NO_RANDOMIZE) +#define PER_CLEAR_ON_SETID (READ_IMPLIES_EXEC) /* * Personality types. Signed-off-by: Samium Gromoff [EMAIL PROTECTED] [1]. See the excellent, 'Hackers Hut' by Andries Brouwer, which describes how AS randomisation can be got around by the means of linux-gate.so.1 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Undo some of the pseudo-security madness
At Sat, 20 Jan 2007 17:37:22 +0300, Samium Gromoff wrote: [snip] So, here we have a buffer-overflow protection technique, which does not actually protect against buffer overflows[1], breaking valid applications. I suggest getting rid of it. i botched it slightly: --- linux/include/linux/personality.h 2007-01-20 17:31:01.0 +0300 +++ linux-sane/include/linux/personality.h 2007-01-20 17:32:50.0 +0300 @@ -40,7 +40,7 @@ * Security-relevant compatibility flags that must be * cleared upon setuid or setgid exec: */ -#define PER_CLEAR_ON_SETID (READ_IMPLIES_EXEC|ADDR_NO_RANDOMIZE) +#define PER_CLEAR_ON_SETID (READ_IMPLIES_EXEC) Signed-off-by: Samium Gromoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
It seems that Tom Lord, the primary architect behind GNU Arch has recently published an open letter to Linus Torvalds. Because no open letter to Linus would be really open without an accompanying reference post on lkml, here it is: http://lists.seyza.com/pipermail/gnu-arch-dev/2005-April/001001.html --- cheers, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
O(0) branching -- a branch is simply a tag, a continuation from some point of development. A network-capable-symlink if you would like. It is actually made possible due to the global Arch namespace. Revision ancestry graph, of course. Enables smart merging. Now, to the features: Archives/revisions are trivially crypto-signed -- thanks to the "stone-simple" on-disk format. Trivial push/pull mirroring -- a mirror is exactly a read-only archive, and can be turned into a full-blown archive by removal of a single file. Revision libraries as client-side operation speedup mechanism with partially automated updates. Cached revisions as server-side speedup. Possibility for hardlinked checkouts for local archives. This requires that your text editor is smart and deletes the original file when it writes changes. Various pre/post/whatever-commit hooks. That much for starters... :-) --- cheers, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
from some point of development. A network-capable-symlink if you would like. It is actually made possible due to the global Arch namespace. Revision ancestry graph, of course. Enables smart merging. Now, to the features: Archives/revisions are trivially crypto-signed -- thanks to the stone-simple on-disk format. Trivial push/pull mirroring -- a mirror is exactly a read-only archive, and can be turned into a full-blown archive by removal of a single file. Revision libraries as client-side operation speedup mechanism with partially automated updates. Cached revisions as server-side speedup. Possibility for hardlinked checkouts for local archives. This requires that your text editor is smart and deletes the original file when it writes changes. Various pre/post/whatever-commit hooks. That much for starters... :-) --- cheers, Samium Gromoff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
It seems that Tom Lord, the primary architect behind GNU Arch has recently published an open letter to Linus Torvalds. Because no open letter to Linus would be really open without an accompanying reference post on lkml, here it is: http://lists.seyza.com/pipermail/gnu-arch-dev/2005-April/001001.html --- cheers, Samium Gromoff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
O_DIRECT! or O_DIRECT?
HI folks, sometime ago i seen on lkml a post from >< regarding the implementation of O_DIRECT. The thing about to care, is the fact, that *nobody*, reacted on this post. It seems to me that nobody was happy enough about this to tell "oh yes! at last!" This is interesting, because one real advantage of O_DIRECT are these greased weasel fast 15-20 Mb/s file copies, which ones makes windoze users to look on us as on lesser beings. I understand, though, that this approach scales bad in the terms of multithread loads, which ones are especially important in server environments, the place linux initially growed from, and that is why it wasn`t already implemented. One more problem i see here, and i think it is an *extremely* important one, that making open( ... , BLA_BLA_BLA | O_DIRECT) is a thing some people may overspeculate with. I mean that implementing O_DIRECT in cp(1), wins the prize, but in the case of, say, find(1) it is definitely not a wise move. The problem may be determined as "poisoning" software with this godblessed O_DIRECT, to the state, when 70% of code on an average machine will use it, thus *completely* killing the advantages of buffered access, and suddenly *bang!*: the overall performance is died. But the worst thing, is what the process of poisoning is completely uncontrollable: each stupid doodie can think, that His shitful piece of Code, is Especially Important, ant that in his case O_DIRECT is perfectly suitable. And in the case His code is someway performance critical, then most likely O_DIRECT will really improve his Code benchmarks, and that is making things really awful, leading to the hell large crowd of pig happy dudes thinking their useless code is life critical, and thus dooming linux. Maybe i`m stupid, as these potential dudes, and painting things in too dark colors, but O_DIRECT, i think, is a dangerous thing to play with. That is why, i think, Linus as far as i can properly recall, wasn`t happy with it et al. Maybe i`m missing the whole point, and thus i want to hear what other people will tell about it. Cheers, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
O_DIRECT! or O_DIRECT?
HI folks, sometime ago i seen on lkml a post from regarding the implementation of O_DIRECT. The thing about to care, is the fact, that *nobody*, reacted on this post. It seems to me that nobody was happy enough about this to tell oh yes! at last! This is interesting, because one real advantage of O_DIRECT are these greased weasel fast 15-20 Mb/s file copies, which ones makes windoze users to look on us as on lesser beings. I understand, though, that this approach scales bad in the terms of multithread loads, which ones are especially important in server environments, the place linux initially growed from, and that is why it wasn`t already implemented. One more problem i see here, and i think it is an *extremely* important one, that making open( ... , BLA_BLA_BLA | O_DIRECT) is a thing some people may overspeculate with. I mean that implementing O_DIRECT in cp(1), wins the prize, but in the case of, say, find(1) it is definitely not a wise move. The problem may be determined as poisoning software with this godblessed O_DIRECT, to the state, when 70% of code on an average machine will use it, thus *completely* killing the advantages of buffered access, and suddenly *bang!*: the overall performance is died. But the worst thing, is what the process of poisoning is completely uncontrollable: each stupid doodie can think, that His shitful piece of Code, is Especially Important, ant that in his case O_DIRECT is perfectly suitable. And in the case His code is someway performance critical, then most likely O_DIRECT will really improve his Code benchmarks, and that is making things really awful, leading to the hell large crowd of pig happy dudes thinking their useless code is life critical, and thus dooming linux. Maybe i`m stupid, as these potential dudes, and painting things in too dark colors, but O_DIRECT, i think, is a dangerous thing to play with. That is why, i think, Linus as far as i can properly recall, wasn`t happy with it et al. Maybe i`m missing the whole point, and thus i want to hear what other people will tell about it. Cheers, Samium Gromoff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] missing adlib release region
i know, adlib_card is just a stupid interface, but
i once was hit by this problem ;).
--- linux-2.4.4.orig/drivers/sound/adlib_card.c Fri May 11 22:42:55 2001
+++ linux-2.4.4/drivers/sound/adlib_card.c Thu May 17 11:39:04 2001
@@ -50,6 +50,7 @@
static void __exit cleanup_adlib(void)
{
+ release_region(cfg.io_base,4);
sound_unload_synthdev(cfg.slots[0]);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] missing adlib release region
i know, adlib_card is just a stupid interface, but
i once was hit by this problem ;).
--- linux-2.4.4.orig/drivers/sound/adlib_card.c Fri May 11 22:42:55 2001
+++ linux-2.4.4/drivers/sound/adlib_card.c Thu May 17 11:39:04 2001
@@ -50,6 +50,7 @@
static void __exit cleanup_adlib(void)
{
+ release_region(cfg.io_base,4);
sound_unload_synthdev(cfg.slots[0]);
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re[2]: ReiserFS 2.4.4/3.x.0k-pre2
Hello, I`m still experiencing file tail corruptions on subj. And more: after i had restored bblocked patrition (by relying on drive`s ability to remap bblks on write by wroting small modification of debugreiserfs which zeroified all bblks), i had _runtime_ tail corruptions of the mc`s dir hotlist which i tried to rewrite again and again. i found, that "sync"ing after modifying helps to keep file fine, so it does until now. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re[2]: ReiserFS 2.4.4/3.x.0k-pre2
Hello, I`m still experiencing file tail corruptions on subj. And more: after i had restored bblocked patrition (by relying on drive`s ability to remap bblks on write by wroting small modification of debugreiserfs which zeroified all bblks), i had _runtime_ tail corruptions of the mc`s dir hotlist which i tried to rewrite again and again. i found, that syncing after modifying helps to keep file fine, so it does until now. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re[2]: ReiserFS question
Info addon, sorry for that: these bblks are quite writeable, so it`s ok to rewrite `em to rebuild. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re[2]: Q: HowTo Nullify journal on badblks?
Hello busy peoples, again me... Today got my 45gb drive slightly badblocked: about 70 MB in beginning... thus problem arose: bitmaps are heavily corrupted, and debugreiserfs with -p crashes while trying to dump journal (he`s not alone in such behaviour: evryone doing that fails with Segfault). I need to dump all metadata to refresh bitmaps etc, but i can`t. 3.x.0j-pre2/linux-2.4.4 what do i have to do? i can provide a strace of segfaulted --fix-fixable thanks in advance - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re[2]: Q: HowTo Nullify journal on badblks?
Hello busy peoples, again me... Today got my 45gb drive slightly badblocked: about 70 MB in beginning... thus problem arose: bitmaps are heavily corrupted, and debugreiserfs with -p crashes while trying to dump journal (he`s not alone in such behaviour: evryone doing that fails with Segfault). I need to dump all metadata to refresh bitmaps etc, but i can`t. 3.x.0j-pre2/linux-2.4.4 what do i have to do? i can provide a strace of segfaulted --fix-fixable thanks in advance - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re[2]: ReiserFS question
Info addon, sorry for that: these bblks are quite writeable, so it`s ok to rewrite `em to rebuild. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ReiserFS question
Hi People... got a following "dead of alive" question: how to find a root block on a ReiserFS partition with a corrupted superblock? reiserfsprogs-3.x.0.9j simply writes -2^32 there at start (reset_super_block) and then simply crashes when attempting to access to such mad place ... got nearly lost my main partition ... sorry for bad english - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ReiserFS question
Hi People... got a following dead of alive question: how to find a root block on a ReiserFS partition with a corrupted superblock? reiserfsprogs-3.x.0.9j simply writes -2^32 there at start (reset_super_block) and then simply crashes when attempting to access to such mad place ... got nearly lost my main partition ... sorry for bad english - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: (iptables) ip_conntrack bug?
vegae:/usr/src/linux# grep -r ./* --regexp="IPS_CON" | grep "define" ./include/linux/elf.h:#define DT_MIPS_CONFLICT 0x7008 ./include/linux/elf.h:#define DT_MIPS_CONFLICTNO0x700b ./include/linux/elf.h:#define SHT_MIPS_CONFLICT 0x7002 vegae:/usr/src/linux# hmmm... looks like theriz no IPS_CONFIRMED definition in test9... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
testXX and PPPD 2.4.0-release
DESCRIPTION: Happen on 2.4.0-testXX, doesnt on 2.2.X pppd 2.4.0-b2,b4,release, ppp async in kernel Sportster 14400 Vi (if that hell does matter) AND! UART 16450! I`ve described such a problem to PPP maintainers about half-year ago, but got nothing. Now it looks like that this problem is /tolerable/ in 2.4.0-testn; n>7, even when in older tests i was just a small hell. PROBLEM ITSELF: ~12.5% of small file transfers stalls at beginning, when modem lights still flashes and ppp0 interface error count significantly grow. it looks like data is there, but ppp refuses to take it. it may look ok, just like some random factor, BUT! *this*happens*on*same*files*or*byte*sequences! e.g. every one of posted on lkml by Dag Brattli irda-posts/mails only downloads by 2.5k, e.g. 2 packets... =( for another example approx 3 of 25 posts on lkml are undownloadable... another detail: tcp_ecn=0 whats the hell? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
testXX and PPPD 2.4.0-release
DESCRIPTION: Happen on 2.4.0-testXX, doesnt on 2.2.X pppd 2.4.0-b2,b4,release, ppp async in kernel Sportster 14400 Vi (if that hell does matter) AND! UART 16450! I`ve described such a problem to PPP maintainers about half-year ago, but got nothing. Now it looks like that this problem is /tolerable/ in 2.4.0-testn; n7, even when in older tests i was just a small hell. PROBLEM ITSELF: ~12.5% of small file transfers stalls at beginning, when modem lights still flashes and ppp0 interface error count significantly grow. it looks like data is there, but ppp refuses to take it. it may look ok, just like some random factor, BUT! *this*happens*on*same*files*or*byte*sequences! e.g. every one of posted on lkml by Dag Brattli irda-posts/mails only downloads by 2.5k, e.g. 2 packets... =( for another example approx 3 of 25 posts on lkml are undownloadable... another detail: tcp_ecn=0 whats the hell? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (iptables) ip_conntrack bug?
vegae:/usr/src/linux# grep -r ./* --regexp="IPS_CON" | grep "define" ./include/linux/elf.h:#define DT_MIPS_CONFLICT 0x7008 ./include/linux/elf.h:#define DT_MIPS_CONFLICTNO0x700b ./include/linux/elf.h:#define SHT_MIPS_CONFLICT 0x7002 vegae:/usr/src/linux# hmmm... looks like theriz no IPS_CONFIRMED definition in test9... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: /proc tweaking
on Tue, 14 Nov 2000 Arjan van de Ven wrote: >In article <[EMAIL PROTECTED]> you wrote: >>Hey people, i`ve got such a thought >> not long ago: >> all boxes are different, but the /proc/sys/vm >> defaults are equal for every people, so there >> is a good issue in getting more performance >> from linux, just by making a way to autoadjust >> these mysterious values according to amount of >> RAM/swap and speed of CPU! Or this can be >done >> in userspace with an utility which look also >> on the field of box` use (eg workstation, >>serveretc...) >> But who can make this better than the >>peoplewho hack the kernel? >> And i wonder why such a issue is not >>clearlycovered? (maybe >>i`m making mistake?) >> This can also be done for >>proc/sys/net/*... > > >Take a look at powertweak. >http://powertweak.sourceforge.net >Made by kernel people, for non-kernel people. Maybe i were not enough exact, but i`ve meant addition of some intelligence to tweaking /proc e.g. something what automates tuning, not only providing interface to such actions. But after lookthru ptweaks source i realized what its ONLY interface (to proc), and MAYBE it does some PCI tuning (really intelligent choices to advance system`s performance). BTW powertweak is a port from unfamous MD, therefore when it was created NO proc tuning was in mind... There is another argument, telling what doingautotune is ugly by design but thats anotherissue. Sorry for poor english/lameness - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
/proc tweaking
Hey people, i`ve got such a thought not long ago: all boxes are different, but the /proc/sys/vm defaults are equal for every people, so there is a good issue in getting more performance from linux, just by making a way to autoadjust these mysterious values according to amount of RAM/swap and speed of CPU! Or this can be done in userspace with an utility which look also on the field of box` use (eg workstation, serveretc...) But who can make this better than the peoplewho hack the kernel? And i wonder why such a issue is not clearlycovered? (maybe i`m making mistake?) This can also be done for proc/sys/net/*... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test9/PPPD2.4.0-release
Maybe i`d better to post this problem to linux-ppp ML, but i`ve reported already it to PPP maintainers about half year ago, thus i felt ok to post here. And so the problem: I`m unable sometimes to get files thru HTTP, and the way its happening is very strange for me: it looks like the packets with file are on place, but kernel rejects `em, fact of what is reflected in significant growth of errors of PPP inteface showed by ifconfig. I checked what error count increase is contemporary with flashing lights on my Sportster 14400 Vi. But thats half of the problem, because this afaik is not a 100% error. It wouldn`t have look that strange for me, if i had that with different files. BUT for ex. i cant get "http://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg12187.html", and that happens with about 20% of small files i retrieve thu web... =(. That problem afaik doesnt extend to large files (e.g >10k) Usually receive stalls on 1 or 2 kbytes. Having 2.4.0-test9/pppd 2.4.0-release. Encountering that ONLY on 2.4.0-testXX series, NOT in 2.2.XX (for ex. 2.2.17 goes well with that). Again, 2.4.N with n<~7 were absolutely unworkable, e.g. the procent of "rejected" small files lied around 80%. Sorry for ugly english/stupidness, i`m foreign non-kernelhacker. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test9/PPPD2.4.0-release
Maybe i`d better to post this problem to linux-ppp ML, but i`ve reported already it to PPP maintainers about half year ago, thus i felt ok to post here. And so the problem: I`m unable sometimes to get files thru HTTP, and the way its happening is very strange for me: it looks like the packets with file are on place, but kernel rejects `em, fact of what is reflected in significant growth of errors of PPP inteface showed by ifconfig. I checked what error count increase is contemporary with flashing lights on my Sportster 14400 Vi. But thats half of the problem, because this afaik is not a 100% error. It wouldn`t have look that strange for me, if i had that with different files. BUT for ex. i cant get "http://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg12187.html", and that happens with about 20% of small files i retrieve thu web... =(. That problem afaik doesnt extend to large files (e.g 10k) Usually receive stalls on 1 or 2 kbytes. Having 2.4.0-test9/pppd 2.4.0-release. Encountering that ONLY on 2.4.0-testXX series, NOT in 2.2.XX (for ex. 2.2.17 goes well with that). Again, 2.4.N with n~7 were absolutely unworkable, e.g. the procent of "rejected" small files lied around 80%. Sorry for ugly english/stupidness, i`m foreign non-kernelhacker. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
/proc tweaking
Hey people, i`ve got such a thought not long ago: all boxes are different, but the /proc/sys/vm defaults are equal for every people, so there is a good issue in getting more performance from linux, just by making a way to autoadjust these mysterious values according to amount of RAM/swap and speed of CPU! Or this can be done in userspace with an utility which look also on the field of box` use (eg workstation, serveretc...) But who can make this better than the peoplewho hack the kernel? And i wonder why such a issue is not clearlycovered? (maybe i`m making mistake?) This can also be done for proc/sys/net/*... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: /proc tweaking
on Tue, 14 Nov 2000 Arjan van de Ven wrote: In article [EMAIL PROTECTED] you wrote: Hey people, i`ve got such a thought not long ago: all boxes are different, but the /proc/sys/vm defaults are equal for every people, so there is a good issue in getting more performance from linux, just by making a way to autoadjust these mysterious values according to amount of RAM/swap and speed of CPU! Or this can be done in userspace with an utility which look also on the field of box` use (eg workstation, serveretc...) But who can make this better than the peoplewho hack the kernel? And i wonder why such a issue is not clearlycovered? (maybe i`m making mistake?) This can also be done for proc/sys/net/*... Take a look at powertweak. http://powertweak.sourceforge.net Made by kernel people, for non-kernel people. Maybe i were not enough exact, but i`ve meant addition of some intelligence to tweaking /proc e.g. something what automates tuning, not only providing interface to such actions. But after lookthru ptweaks source i realized what its ONLY interface (to proc), and MAYBE it does some PCI tuning (really intelligent choices to advance system`s performance). BTW powertweak is a port from unfamous MD, therefore when it was created NO proc tuning was in mind... There is another argument, telling what doingautotune is ugly by design but thats anotherissue. Sorry for poor english/lameness - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
just a small VM idea
Let`s imagine were having two mounted swap partitions. Current situation, if im not going wrong is the next: swapping to 1st partition, till there is a space on it then swapping to the next one... But if make two basic checks: 1) if these partitions are on different drives 2) i/o speed is approx the same we can do parallel page writes/reads, therefore in fact twicing swapping i/o... sorry for my ugly english/lameness - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
just a small VM idea
Let`s imagine were having two mounted swap partitions. Current situation, if im not going wrong is the next: swapping to 1st partition, till there is a space on it then swapping to the next one... But if make two basic checks: 1) if these partitions are on different drives 2) i/o speed is approx the same we can do parallel page writes/reads, therefore in fact twicing swapping i/o... sorry for my ugly english/lameness - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
