| Age | Commit message (Collapse) | Author |
|---|
|
I ran into a couple of programs which broke with the new Linux 3.0
version. Some of those were binary only. I tried to use LD_PRELOAD to
work around it, but it was quite difficult and in one case impossible
because of a mix of 32bit and 64bit executables.
For example, all kind of management software from HP doesnt work, unless
we pretend to run a 2.6 kernel.
$ uname -a
Linux svivoipvnx001 3.0.0-08107-g97cd98f #1062 SMP Fri Aug 12 18:11:45 CEST 2011 i686 i686 i386 GNU/Linux
$ hpacucli ctrl all show
Error: No controllers detected.
$ rpm -qf /usr/sbin/hpacucli
hpacucli-8.75-12.0
Another notable case is that Python now reports "linux3" from
sys.platform(); which in turn can break things that were checking
sys.platform() == "linux2":
https://bugzilla.mozilla.org/show_bug.cgi?id=664564
It seems pretty clear to me though it's a bug in the apps that are using
'==' instead of .startswith(), but this allows us to unbreak broken
programs.
This patch adds a UNAME26 personality that makes the kernel report a
2.6.40+x version number instead. The x is the x in 3.x.
I know this is somewhat ugly, but I didn't find a better workaround, and
compatibility to existing programs is important.
Some programs also read /proc/sys/kernel/osrelease. This can be worked
around in user space with mount --bind (and a mount namespace)
To use:
wget ftp://ftp.kernel.org/pub/linux/kernel/people/ak/uname26/uname26.c
gcc -o uname26 uname26.c
./uname26 program
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
of u_long
task_struct->pesonality is "unsigned int", but sys_personality() paths use
"unsigned long pesonality". This means that every assignment or
comparison is not right. In particular, if this argument does not fit
into "unsigned int" __set_personality() changes the caller's personality
and then sys_personality() returns -EINVAL.
Turn this argument into "unsigned int" and avoid overflows. Obviously,
this is the user-visible change, we just ignore the upper bits. But this
can't break the sane application.
There is another thing which can confuse the poorly written applications.
User-space thinks that this syscall returns int, not long. This means
that the returned value can be negative and look like the error code. But
note that libc won't be confused and thus errno won't be set, and with
this patch the user-space can never get -1 unless sys_personality() really
fails. And, most importantly, the negative RET != -1 is only possible if
that app previously called personality(RET).
Pointed-out-by: Wenming Zhang <wezhang@redhat.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
We have found that the current PER_CLEAR_ON_SETID mask on Linux doesn't
include neither ADDR_COMPAT_LAYOUT, nor MMAP_PAGE_ZERO.
The current mask is READ_IMPLIES_EXEC|ADDR_NO_RANDOMIZE.
We believe it is important to add MMAP_PAGE_ZERO, because by using this
personality it is possible to have the first page mapped inside a
process running as setuid root. This could be used in those scenarios:
- Exploiting a NULL pointer dereference issue in a setuid root binary
- Bypassing the mmap_min_addr restrictions of the Linux kernel: by
running a setuid binary that would drop privileges before giving us
control back (for instance by loading a user-supplied library), we
could get the first page mapped in a process we control. By further
using mremap and mprotect on this mapping, we can then completely
bypass the mmap_min_addr restrictions.
Less importantly, we believe ADDR_COMPAT_LAYOUT should also be added
since on x86 32bits it will in practice disable most of the address
space layout randomization (only the stack will remain randomized).
Signed-off-by: Julien Tinnes <jt@cr0.org>
Signed-off-by: Tavis Ormandy <taviso@sdf.lonestar.org>
Cc: stable@kernel.org
Acked-by: Christoph Hellwig <hch@infradead.org>
Acked-by: Kees Cook <kees@ubuntu.com>
Acked-by: Eugene Teo <eugene@redhat.com>
[ Shortened lines and fixed whitespace as per Christophs' suggestion ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Remove the macro get_personality, use ->personality instead.
Cc: Christoph Hellwig <hch@infradead.org
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Bryan Wu <bryan.wu@analog.com>
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
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 <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
<linux/personality.h> 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 <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
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 <arjan@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
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 <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
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 <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
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 <command>" will run the command with the old layout.
From: Hugh Dickins <hugh@veritas.com>
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 <mingo@elte.hu>
- 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 <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
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 <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
From: Andi Kleen <ak@muc.de>
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.
|
|
A second start at removing them from kernel/*.c and fs/*.c.
Note that module_put is fine for a NULL argument.
|
|
Some might argue that HPUX already has quite enough of a personality.
|
|
- osf_getrusage() updated for new utime/stime fields of the task_struct;
- compatibility wrappers for OSF/1 v4 readv/writev syscalls:
forward port from 2.4.19.
|
|
- Christoph Hellwig: clean up personality handling a bit
- Robert Love: update sysctl/vm documentation
- make the three-argument (that everybody hates) "min()" be "min_t()",
and introduce a type-anal "min()" that complains about arguments of
different types.
|
|
|
