Skip to content

L
linux
Switch branch/tag
  1. 24 Jul, 2004 3 commits
  3. 23 Jul, 2004 2 commits
    • Anton Blanchard's avatar
      [PATCH] Fix ppc64 max_pfn issue · 1172fbd0
      Anton Blanchard authored 
      I noticed excessive time in the pid hash functions on a ppc64 box. It
turns out the pid hash is being sized way too small, eg on a 16GB box:

PID hash table entries: 16 (order 4: 256 bytes)

The reason is that the pid hash init function uses max_pfn before it was
setup on ppc64. With the following patch things are good again:

PID hash table entries: 4096 (order 12: 65536 bytes)
Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      1172fbd0
    • David Mosberger's avatar
      [PATCH] NX: allow architectures to select legacy mode dynamically · 2813e143
      David Mosberger authored 
      On some platforms, you'll want to support READ_IMPLIES_EXEC differently
depending on personality (e.g, native binary vs. x86 binary).

This supports that (and makes the code more readable while at it) by
replacing the old architecture-specific fixed LEGACY_BINARIES macro
define with a architecture-specific "elf_read_implies_exec_binary()"
helper function.

For now, x86 is the only user, and sets the "read implies exec" bit for
legacy apps.  ia64 and x86-64 are likely to want to do their own thing.

Acked by Ingo.
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      2813e143
  5. 22 Jul, 2004 10 commits
  7. 21 Jul, 2004 16 commits
  9. 20 Jul, 2004 5 commits
  11. 18 Jul, 2004 2 commits
    • Ingo Molnar's avatar
      [PATCH] NX: clean up legacy binary support · 1bb0fa18
      Ingo Molnar authored 
      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: default avatarIngo Molnar <mingo@elte.hu>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      1bb0fa18
    • David Eger's avatar
      [PATCH] pmac_zilog: serial minors taken failure path fix · 4e8688b2
      David Eger authored 
      I've tracked down the core issue giving me the oops wrt pmac_zilog.

When you have two serial drivers, (e.g. 8250 and PMAC_ZILOG) they both say

"I want to reserve X ports starting with major TTY_MAJOR and minor 64".

By the time pmac_zilog gets there, the ports it requests are already
reserved.  Unfortunately, init_pmz() doesn't check for pmz_register()
failure, and so it merrily goes on to register the half-initialized
pmac_zilog driver with the power management subsystem.

This path provides a proper failure path.

Also: 

Restore ppc configs now that I know people use AT Keyboards on CHRP and PReP
machines, and the zilog driver is no longer Oops'ing.
Signed-off-by: default avatarDavid Eger <eger@havoc.gtf.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      4e8688b2
  13. 17 Jul, 2004 2 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7