Re: importing 2.6.25-rc1
On Mon, Feb 11, 2008 at 01:50:00PM -0800, Roland McGrath wrote: M linux-2.6-i386-vdso-install-unstripped-copies-on-disk.patch needs a bit of inspection, looks right (and builds ok) This one should be upstream now. If anything is still missing, I should be able to get it in for 2.6.25. I needed the following patch to be able to build the fedora rpms on i386. This is likely a case of the new code doing the right thing, but me not being able to figure out the debug stuff in the spec file at the time though. cheers, Kyle diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile index d28dda5..dcbca17 100644 --- a/arch/x86/vdso/Makefile +++ b/arch/x86/vdso/Makefile @@ -7,8 +7,9 @@ VDSO32-$(CONFIG_X86_32) := y VDSO32-$(CONFIG_COMPAT):= y vdso-install-$(VDSO64-y) += vdso.so -vdso-install-$(VDSO32-y) += $(vdso32-y:=.so) - +vdso-install-$(VDSO32-y) += vdso32-sysenter.so $(vdso32-y:=.so) +vdso-install-$(CONFIG_X86_32) += vdso32-int80.so +vdso-install-$(CONFIG_COMPAT) += vdso32-syscall.so # files to link into the vdso vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o vvar.o ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: importing 2.6.25-rc1
M linux-2.6-i386-vdso-install-unstripped-copies-on-disk.patch needs a bit of inspection, looks right (and builds ok) This one should be upstream now. If anything is still missing, I should be able to get it in for 2.6.25. M linux-2.6-utrace-core.patch M linux-2.6-utrace-tracehook.patch pull-upstream.sh didn't fix this... so commented out in the build I'm behind on the rebasing. Just leave it for me to sort out. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: importing 2.6.25-rc1
On Mon, Feb 11, 2008 at 01:54:25PM -0500, Jarod Wilson wrote: On Monday 11 February 2008 12:53:40 pm Kyle McMartin wrote: git trees: firewire - commented out, pending didn't apply Yeah, the pending bits depend on some bits that are in linux1394-git that haven't yet made their way over to Linus, I believe. Figure I'll just fix things up after the rebase. if you want, you can attach a diff here and i'll put it into the first upload, or commit it with something like pending-rc1.patch or something and i'll move it when we update. cheers, kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: importing 2.6.25-rc1
I needed the following patch to be able to build the fedora rpms on i386. This is likely a case of the new code doing the right thing, but me not being able to figure out the debug stuff in the spec file at the time though. I sent a fix upstream for that. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: importing 2.6.25-rc1
On Monday 11 February 2008 12:53:40 pm Kyle McMartin wrote: git trees: firewire - commented out, pending didn't apply Yeah, the pending bits depend on some bits that are in linux1394-git that haven't yet made their way over to Linus, I believe. Figure I'll just fix things up after the rebase. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: execshield inspection needed
On Sun, Feb 10, 2008 at 08:43:32PM -0500, Kyle McMartin wrote:
x86-merge has kind of thrown a spanner in the execshield patchset. I've
merged it up so it looks like it works, but I'd like to get some input
from others to make sure I didn't brown-paper-bag it.
The randomization bits seem to have been merged upstream, but I deferred
to the execshield implementation since they had some differences.
cheers,
Kyle
[linux-2.6-execshield.patch is attached.]
i appear to have noviced it and truncated the patch. i remerged it
against rc1... seems to work. i hope...
cheers,
kyle
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index f86a3c4..4c5f70d 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -478,6 +478,13 @@ void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
* we do generic changes.
*/
+ if (exec_shield != 0) {
+#ifdef CONFIG_X86_PAE
+ if (!test_bit(X86_FEATURE_NX, c-x86_capability))
+#endif
+ clear_bit(X86_FEATURE_SEP, c-x86_capability);
+ }
+
/* If the model name is still unset, do table lookup. */
if ( !c-x86_model_id[0] ) {
char *p;
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index a7d50a5..83f7b4e 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -677,7 +677,8 @@ struct task_struct * __switch_to(struct task_struct
*prev_p, struct task_struct
/* never put a printk in __switch_to... printk() calls wake_up*()
indirectly */
__unlazy_fpu(prev_p);
-
+ if (next_p-mm)
+ load_user_cs_desc(cpu, next_p-mm);
/* we're going to use this soon, after a few expensive things */
if (next_p-fpu_counter 5)
@@ -842,8 +843,58 @@ unsigned long arch_align_stack(unsigned long sp)
return sp ~0xf;
}
-unsigned long arch_randomize_brk(struct mm_struct *mm)
+void arch_add_exec_range(struct mm_struct *mm, unsigned long limit)
+{
+ if (limit mm-context.exec_limit) {
+ mm-context.exec_limit = limit;
+ set_user_cs(mm-context.user_cs, limit);
+ if (mm == current-mm) {
+ preempt_disable();
+ load_user_cs_desc(smp_processor_id(), mm);
+ preempt_enable();
+ }
+ }
+}
+
+void arch_remove_exec_range(struct mm_struct *mm, unsigned long old_end)
{
- unsigned long range_end = mm-brk + 0x0200;
- return randomize_range(mm-brk, range_end, 0) ? : mm-brk;
+ struct vm_area_struct *vma;
+ unsigned long limit = PAGE_SIZE;
+
+ if (old_end == mm-context.exec_limit) {
+ for (vma = mm-mmap; vma; vma = vma-vm_next)
+ if ((vma-vm_flags VM_EXEC) (vma-vm_end limit))
+ limit = vma-vm_end;
+
+ mm-context.exec_limit = limit;
+ set_user_cs(mm-context.user_cs, limit);
+ if (mm == current-mm) {
+ preempt_disable();
+ load_user_cs_desc(smp_processor_id(), mm);
+ preempt_enable();
+ }
+ }
+}
+
+void arch_flush_exec_range(struct mm_struct *mm)
+{
+ mm-context.exec_limit = 0;
+ set_user_cs(mm-context.user_cs, 0);
+}
+
+/*
+ * Generate random brk address between 128MB and 196MB. (if the layout
+ * allows it.)
+ */
+void randomize_brk(unsigned long old_brk)
+{
+ unsigned long new_brk, range_start, range_end;
+
+ range_start = 0x0800;
+ if (current-mm-brk = range_start)
+ range_start = current-mm-brk;
+ range_end = range_start + 0x0200;
+ new_brk = randomize_range(range_start, range_end, 0);
+ if (new_brk)
+ current-mm-brk = new_brk;
}
diff --git a/arch/x86/kernel/setup64.c b/arch/x86/kernel/setup64.c
index 309366f..8a940dc 100644
--- a/arch/x86/kernel/setup64.c
+++ b/arch/x86/kernel/setup64.c
@@ -45,46 +45,6 @@ EXPORT_SYMBOL_GPL(__supported_pte_mask);
static int do_not_nx __cpuinitdata = 0;
-/* noexec=on|off
-Control non executable mappings for 64bit processes.
-
-on Enable(default)
-offDisable
-*/
-static int __init nonx_setup(char *str)
-{
- if (!str)
- return -EINVAL;
- if (!strncmp(str, on, 2)) {
-__supported_pte_mask |= _PAGE_NX;
- do_not_nx = 0;
- } else if (!strncmp(str, off, 3)) {
- do_not_nx = 1;
- __supported_pte_mask = ~_PAGE_NX;
-}
- return 0;
-}
-early_param(noexec, nonx_setup);
-
-int force_personality32 = 0;
-
-/* noexec32=on|off
-Control non executable heap for 32bit processes.
-To control the stack too use noexec=off
-
-on PROT_READ does not imply PROT_EXEC for 32bit processes
-offPROT_READ implies PROT_EXEC (default)
-*/
-static int __init nonx32_setup(char *str)
-{
- if
Re: selinux patch
On Mon, 2008-02-11 at 09:38 -0500, Dave Jones wrote: On Mon, Feb 11, 2008 at 09:32:29AM -0500, Stephen Smalley wrote: Could the patch below (already in Linus' git tree for 2.6.25) be added to the rawhide kernel? It is to support polyinstantiation by XACE/XSELinux. fwiw, rawhide should be moving to .25rc1-git sometime this week. Ok, thanks - we'll wait for that then. -- Stephen Smalley National Security Agency ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
selinux patch
Hi,
Could the patch below (already in Linus' git tree for 2.6.25) be added
to the rawhide kernel? It is to support polyinstantiation by
XACE/XSELinux.
Gitweb:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2e08c0c1c3977a5ddc7dd3af1b26c433e9d0
Commit: 2e08c0c1c3977a5ddc7dd3af1b26c433e9d0
Parent: 1996a10948e50e546dc2b64276723c0b64d3173b
Author: Eamon Walsh [EMAIL PROTECTED]
AuthorDate: Thu Jan 24 15:30:52 2008 -0500
Committer: James Morris [EMAIL PROTECTED]
CommitDate: Fri Jan 25 11:29:56 2008 +1100
selinux: make mls_compute_sid always polyinstantiate
This patch removes the requirement that the new and related object types
differ in order to polyinstantiate by MLS level. This allows MLS
polyinstantiation to occur in the absence of explicit type_member rules or
when the type has not changed.
Potential users of this support include pam_namespace.so (directory
polyinstantiation) and the SELinux X support (property polyinstantiation).
Signed-off-by: Eamon Walsh [EMAIL PROTECTED]
Acked-by: Stephen Smalley [EMAIL PROTECTED]
Signed-off-by: James Morris [EMAIL PROTECTED]
---
security/selinux/ss/mls.c | 11 ++-
1 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/security/selinux/ss/mls.c b/security/selinux/ss/mls.c
index fb5d70a..3bbcb53 100644
--- a/security/selinux/ss/mls.c
+++ b/security/selinux/ss/mls.c
@@ -537,15 +537,8 @@ int mls_compute_sid(struct context *scontext,
/* Use the process effective MLS attributes. */
return mls_context_cpy_low(newcontext, scontext);
case AVTAB_MEMBER:
- /* Only polyinstantiate the MLS attributes if
- the type is being polyinstantiated */
- if (newcontext-type != tcontext-type) {
- /* Use the process effective MLS attributes. */
- return mls_context_cpy_low(newcontext, scontext);
- } else {
- /* Use the related object MLS attributes. */
- return mls_context_cpy(newcontext, tcontext);
- }
+ /* Use the process effective MLS attributes. */
+ return mls_context_cpy_low(newcontext, scontext);
default:
return -EINVAL;
}
--
Stephen Smalley
National Security Agency
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: execshield inspection needed
Your attachment was empty. The execshield patch has gotten much smaller than it was in the beginning. It still hasn't gotten all the cleanup it could get though. The patch does a few different things that ideally would be in separate patches. 1. Segment-based PAGE_EXEC for no-NX hardware (and non-PAE 32-bit kernels). This is not really very much code. There's the GPF trap handler, and the hooks like arch_add_exec_range et al. I don't see why this couldn't be merged upstream as a config option. 2. Tighter permissions on /proc/pid/foo. This would be simple to make a config option and is such a simple patch (fs/proc/base.c) it seems like it shouldn't be hard to get upstream. 3. get_unmapped_area_prot. This is what changes the layouts and is the heart of what's really exec-shield since randomization has been upstream. 4. Miscellaneous tweaks and cruft. There are strange little bits of diff that I don't know the explanation for. Maybe we can clean these up. I hope Ingo knows what any other bits in there are for. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: importing 2.6.25-rc1
On Mon, 2008-02-11 at 12:53 -0500, Kyle McMartin wrote: somewhat upstream... i merged-ish it, upstream version needs you to reset the mac address with ip which is kind of loss. why has nobody root-caused this failure yet? :/ The root cause, at least for me, was that the motherboard has crappy shielding and swapping video cards is sufficient to taze the EEPROM. - ajax ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
importing 2.6.25-rc1
git trees: firewire - commented out, pending didn't apply ext4 - commented out, seems upstream wireless - mostly upstream, pending didn't apply M linux-2.6-acpi-eeepc-hotkey.patch fixed rejects M linux-2.6-e1000-corrupt-eeprom-checksum.patch somewhat upstream... i merged-ish it, upstream version needs you to reset the mac address with ip which is kind of loss. why has nobody root-caused this failure yet? :/ R linux-2.6-agp-mm.patch upstream R linux-2.6-alsa-rc4-mm1.patch R linux-2.6-alsa-support-sis7019.patch upstream (obviously :) M linux-2.6-build-nonintconfig.patch M linux-2.6-compile-fix-gcc-43.patch M linux-2.6-crash-driver.patch fixed rejects R linux-2.6-dcdbas-autoload.patch upstream M linux-2.6-debug-no-quiet.patch M linux-2.6-debug-sizeof-structs.patch M linux-2.6-debug-taint-vm.patch more rejects M linux-2.6-devmem.patch fixed rejects... maybe needs merging upstream R linux-2.6-drm-mm.patch R linux-2.6-drm-radeon-update.patch R linux-2.6-git-initial-r500-drm.patch upstream M linux-2.6-execshield.patch rejects fixed (hopefully) R linux-2.6-futex-fix-fixups.patch upstream M linux-2.6-gelic-fixups.patch M linux-2.6-input-kill-stupid-messages.patch M linux-2.6-lirc.patch M linux-2.6-silence-noise.patch M linux-2.6-squashfs.patch trivial rejects M linux-2.6-i386-vdso-install-unstripped-copies-on-disk.patch needs a bit of inspection, looks right (and builds ok) R linux-2.6-libata-pegasos-fix.patch upstream R linux-2.6-netdev-bonding-fix-null-deref.patch R linux-2.6-pasemi-for-2.6.25.patch R linux-2.6-pasemi-reserve-i2c.patch R linux-2.6-powerpc-bootwrapper.patch R linux-2.6-powerpc-generic-suspend-001-pmu-no-lock-kernel.patch R linux-2.6-powerpc-generic-suspend-002-pmu-remove-dead-code.patch R linux-2.6-powerpc-generic-suspend-003-remove-adb-sleep-notifier.patch R linux-2.6-powerpc-generic-suspend-004-kill-pmu-sleep-notifier.patch R linux-2.6-powerpc-generic-suspend-005-proper-sleep-management.patch R linux-2.6-unexport-symbols.patch upstream R linux-2.6-rndis_wlan.patch upstream? M linux-2.6-utrace-core.patch M linux-2.6-utrace-tracehook.patch pull-upstream.sh didn't fix this... so commented out in the build R linux-2.6-xfs-optimize-away-realtime-tests.patch R linux-2.6-xfs-setfattr-32bit-compat.patch R linux-2.6-xfs-xfs_mount-refactor.patch upstream(?) M nouveau-drm.patch rejects fixed... maybe should be updated... airlied? M sources M upstream ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: selinux patch
On Mon, Feb 11, 2008 at 09:32:29AM -0500, Stephen Smalley wrote: Could the patch below (already in Linus' git tree for 2.6.25) be added to the rawhide kernel? It is to support polyinstantiation by XACE/XSELinux. fwiw, rawhide should be moving to .25rc1-git sometime this week. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: importing 2.6.25-rc1
On Mon, Feb 11, 2008 at 12:53:40PM -0500, Kyle McMartin wrote: M linux-2.6-e1000-corrupt-eeprom-checksum.patch somewhat upstream... i merged-ish it, upstream version needs you to reset the mac address with ip which is kind of loss. why has nobody root-caused this failure yet? :/ I spoke with DaveM about this at LCA. Aparently we don't need it anymore. M linux-2.6-devmem.patch fixed rejects... maybe needs merging upstream needs to be dropped in favour of the version arjan is pushing upstream (might be too late for .25, but probable .26 material) Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Fedora kernel build failure: *** ERROR: same build ID in nonidentical files!
David is correct that eu-elfcmp is meant to see the stripped and unstripped files as matching. Josh is correct that the .gnu.attributes section is the new thing that is provoking the problem, owing to GCC 4.3. I'm doing three things: 1. elfcmp's bug is that it sees the .gnu.attribute sections in the stripped and unstripped files as nonidentical. This is a new section generated by GCC 4.3, which is not allocated but also is not stripped. So in the stripped file, its sh_offset (file position) moves when the other nonallocated sections are removed. I'll fix it upstream to ignore sh_offset in the cases where doesn't matter. This won't hit rawhide especially soon. (I'll also deal with the elfutils vs 4.3 on ppc issues Josh saw, but that is not anything to do with the kernel build.) This is moot wrt breaking the kernel build because of #3. 2. Part of the debuginfo_args magic macro's regexp was wrong, so it failed to match the /boot files. This is why /usr/lib/debug/boot/*.debug all wound up in kernel-debuginfo-common. I fixed the regexp so the .debug files for any unstripped ELF files in /boot will be sorted into the right kernel-debuginfo subpackage as originally intended. This is moot wrt reducing the total debuginfo rpm bloat because of #3. 3. We already copy the unstripped vmlinux into /usr/lib/debug. (This is whence arises the comparison that hit bug #1.) So .debug files stripped from an ELF vmlinux installed into /boot just duplicates the bulky part of that, and bloats that debuginfo rpm. (With bug #2 fixed, this bloat is properly sorted into each kernel-debuginfo and kernel-foo-debuginfo rather than going into kernel-debuginfo-common.) People prefer just having the unstripped vmlinux installed by kernel-debuginfo even when a split ELF /boot/vmlinux and .debug are available. It's simpler, and has the whole thing just by installing a kernel-debuginfo rpm without installing that kernel rpm in /boot. So, to dump the bloat we keep only one, and the unstripped vmlinux wins. The way to dump the /usr/lib/debug/boot/*.debug files is to strip the vmlinux we copy into /boot. I've changed BuildKernel to do this. There are no other files that ever should have matched the part of the regexp that was wrong in bug #2, so that fix is masked by this change. Since the /boot files will be seen as stripped, they won't be processed by find-debuginfo.sh at all. This circumvents bug #1. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
