Re: [PATCH] Undo some of the pseudo-security madness

ext 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

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 an

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

Re: [PATCH] Undo some of the pseudo-security madness

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

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 lef

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 lef

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 EL

[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

[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

[PATCH 0/2] Mechanism to turn of ASR on a per-ELF binary basis

. 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

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 implementati

[PATCH 0/2] Mechanism to turn of ASR on a per-ELF binary basis

. 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

[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

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

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

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

Re: [PATCH] Undo some of the pseudo-security madness

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

Re: [PATCH] Undo some of the pseudo-security madness

l 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]

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 progr

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

Re: [PATCH] Undo some of the pseudo-security madness

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

Re: [PATCH] Undo some of the pseudo-security madness

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 (a

Re: [PATCH] Undo some of the pseudo-security madness

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 majordom

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 &g

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

[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

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 con

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 consis

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

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

[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

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

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

Re: [PATCH] Undo some of the pseudo-security madness

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

Re: [PATCH] Undo some of the pseudo-security madness

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

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/i

[PATCH] Undo some of the pseudo-security madness

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 describ

[PATCH] Undo some of the pseudo-security madness

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

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

Re: Kernel SCM saga..

.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..

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 l

Re: Kernel SCM saga..

. 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

Re: Kernel SCM saga..

.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?

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 "unsubs

O_DIRECT! or O_DIRECT?

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

[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)

[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)

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

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

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

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

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

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

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

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

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#

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

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

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#

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

/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

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

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

/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

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

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

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