user/sven/linux.git/include/linux/personality.h, branch tmp/leds/core

Remove the macro get_personality

2008-04-29T15:06:02Z

Remove the macro get_personality, use ->personality instead. Cc: Christoph Hellwig Cc: David Howells Cc: Bryan Wu Signed-off-by: WANG Cong Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Fix missing parens in set_personality()

2006-11-13T15:40:42Z

If you call set_personality() with an expression such as: set_personality(foo ? PERS_FOO1 : PERS_FOO2); then this evaluates to: ((current->personality == foo ? PERS_FOO1 : PERS_FOO2) ? ... which is obviously not the intended result. Add the missing parents to ensure this gets evaluated as expected: ((current->personality == (foo ? PERS_FOO1 : PERS_FOO2)) ? ... Signed-off-by: Russell King Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Make userspace proof

2006-10-20T17:26:35Z

contains the constants for personality(2) but also some defintions that are useless or even harmful in userspace such as the personality() macro. Signed-off-by: Ralf Baechle Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Randomisation: add ADDR_NO_RANDOMIZE personality

2005-03-05T01:25:55Z

Introduce a personality that disables randomisation, so that users can use setarch and related commands to run specific applications without randomisation. Signed-off-by: Arjan van de Ven Signed-off-by: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] FRV: Add FDPIC ELF binary format driver

2005-01-04T13:21:32Z

The attached patch adds a new binary format driver that allows a special variety of ELF to be used that permits the dynamic sections that comprise an executable, its dynamic loader and its shared libaries and its stack and data to be located anywhere within the address space. This is used to provide shared libraries and shared executables (at least, as far as the read-only dynamic sections go) on uClinux. Not only that, but the same binaries can be run on MMU linux without a problem. This is achieved by: (1) Passing loadmaps to the dynamic loader (or to a statically linked executable) to indicate the whereabouts of the various dynamic sections. (2) Using a GOT inside the program. (3) Passing setup_arg_pages() the stack pointer to be. (4) Allowing the arch greated control over how an executable is laid out in memory in MMU Linux. (5) Rewriting mm/nommu.c to support MAP_PRIVATE on files, thus allowing _mmap_ to handle sharing of private-readonly mappings. Signed-Off-By: David Howells Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] remove unused sysctls from kernel/personality.c

2004-09-08T00:50:53Z

These are only used by the out of tree linux-abi project, so it makes sense to define them in those modules. Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] i386 virtual memory layout rework

2004-08-24T04:11:50Z

Rework the i386 mm layout to allow applications to allocate more virtual memory, and larger contiguous chunks. - the patch is compatible with existing architectures that either make use of HAVE_ARCH_UNMAPPED_AREA or use the default mmap() allocator - there is no change in behavior. - 64-bit architectures can use the same mechanism to clean up 32-bit compatibility layouts: by defining HAVE_ARCH_PICK_MMAP_LAYOUT and providing a arch_pick_mmap_layout() function - which can then decide between various mmap() layout functions. - I also introduced a new personality bit (ADDR_COMPAT_LAYOUT) to signal older binaries that dont have PT_GNU_STACK. x86 uses this to revert back to the stock layout. I also changed x86 to not clear the personality bits upon exec(), like x86-64 already does. - once every architecture that uses HAVE_ARCH_UNMAPPED_AREA has defined its arch_pick_mmap_layout() function, we can get rid of HAVE_ARCH_UNMAPPED_AREA altogether, as a final cleanup. the new layout generation function (__get_unmapped_area()) got significant testing in FC1/2, so i'm pretty confident it's robust. Compiles & boots fine on an 'old' and on a 'new' x86 distro as well. The two known breakages were: http://www.redhatconfig.com/msg/67248.html [ 'cyzload' third-party utility broke. ] http://www.zipworld.com/au/~akpm/dde.tar.gz [ your editor broke :-) ] both were caused by application bugs that did: int ret = malloc(); if (ret <= 0) failure; such bugs are easy to spot if they happen, and if it happens it's possible to work it around immediately without having to change the binary, via the setarch patch. No other application has been found to be affected, and this particular change got pretty wide coverage already over RHEL3 and exec-shield, it's in use for more than a year. The setarch utility can be used to trigger the compatibility layout on x86, the following version has been patched to take the `-L' option: http://people.redhat.com/mingo/flexible-mmap/setarch-1.4-2.tar.gz "setarch -L i386 " will run the command with the old layout. From: Hugh Dickins The problem is in the flexible mmap patch: arch_get_unmapped_area_topdown is liable to give your mmap vm_start above TASK_SIZE with vm_end wrapped; which is confusing, and ends up as that BUG_ON(mm->map_count). The patch below stops that behaviour, but it's not the full solution: wilson_mmap_test -s 1000 then simply cannot allocate memory for the large mmap, whereas it works fine non-top-down. I think it's wrong to interpret a large or rlim_infinite stack rlimit as an inviolable request to reserve that much for the stack: it makes much less VM available than bottom up, not what was intended. Perhaps top down should go bottom up (instead of belly up) when it fails - but I'd probably better leave that to Ingo. Or perhaps the default should place stack below text (as WLI suggested and ELF intended, with its text defaulting to 0x08048000, small progs sharing page table between stack and text and data); with a further personality for those needing bigger stack. From: Ingo Molnar - fall back to the bottom-up layout if the stack can grow unlimited (if the stack ulimit has been set to RLIM_INFINITY) - try the bottom-up allocator if the top-down allocator fails - this can utilize the hole between the true bottom of the stack and its ulimit, as a last-resort effort. Signed-off-by: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] NX: clean up legacy binary support

2004-07-18T02:08:19Z

This cleans up legacy x86 binary support by introducing a new personality bit: READ_IMPLIES_EXEC, and implements Linus' suggestion to add the PROT_EXEC bit on the two affected syscall entry places, sys_mprotect() and sys_mmap(). If this bit is set then PROT_READ will also add the PROT_EXEC bit - as expected by legacy x86 binaries. The ELF loader will automatically set this bit when it encounters a legacy binary. This approach avoids the problems the previous ->def_flags solution caused. In particular this patch fixes the PROT_NONE problem in a cleaner way (http://lkml.org/lkml/2004/7/12/227), and it should fix the ia64 PROT_EXEC problem reported by David Mosberger. Also, mprotect(PROT_READ) done by legacy binaries will do the right thing as well. the details: - the personality bit is added to the personality mask upon exec(), within the ELF loader, but is not cleared (see the exceptions below). This means that if an environment that already has the bit exec()s a new-style binary it will still get the old behavior. - one exception are setuid/setgid binaries: these will reset the bit - thus local attackers cannot manually set the bit and circumvent NX protection. Legacy setuid binaries will still get the bit through the ELF loader. This gives us maximum flexibility in shaping compatibility environments. - selinux also clears the bit when switching SIDs via exec(). - x86 is the only arch making use of READ_IMPLIES_EXEC currently. Other arches will have the pre-NX-patch protection setup they always had. I have booted an old distro [RH 7.2] and two new PT_GNU_STACK distros [SuSE 9.2 and FC2] on an NX-capable CPU - they work just fine and all the mapping details are right. I've checked the PROT_NONE test-utility as well and it works as expected. I have checked various setuid scenarios as well involving legacy and new-style binaries. an improved setarch utility can be used to set the personality bit manually: http://redhat.com/~mingo/nx-patches/setarch-1.4-3.tar.gz the new '-X' flag does it, e.g.: ./setarch -X linux /bin/cat /proc/self/maps will trigger the old protection layout even on a new distro. Signed-off-by: Ingo Molnar Signed-off-by: Linus Torvalds

[PATCH] Add 3GB personality

2003-08-31T11:27:21Z

From: Andi Kleen Another a bit ugly but necessary patch for 32bit emulation. Some applications including some versions of java break when the stack is beyond the i386 standard 3GB boundary. For these add a 3GB personality that moves the stack to 3GB and fixes the beginning of the mmap area. It's a bit ugly, but better than not running these applications at all (e.g. the Oracle installer depends on such a buggy java :-(). It's also not only Java, but some other programs as well.

[PATCH] avoid deprecated module functions in core code

2002-12-29T08:40:46Z

A second start at removing them from kernel/*.c and fs/*.c. Note that module_put is fine for a NULL argument.