* Re: PowerPC paxtest results w/ gcc-4.1
From: Alan Modra @ 2006-08-13 3:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Albert Cahalan, linuxppc-dev, debian-powerpc
In-Reply-To: <17630.27174.711916.643790@cargo.ozlabs.ibm.com>
On Sun, Aug 13, 2006 at 09:54:14AM +1000, Paul Mackerras wrote:
> To get the full benefit of -msecure-plt, every object file in your
> executable has to be compiled with it
Yes. In particular, glibc startup files need to be compiled with
-msecure-plt. If ld links any object file that uses the old scheme
requiring an executable .got into the executable, then the old layout is
forced.
>, and I think every shared
> library the program uses has to be compiled with it too.
No, this isn't necessary.
> On a system
> where everything has been compiled with -msecure-plt, I believe the
> heap and stack will automatically be made non-executable.
Exec stack is a separate issue from the plt/got layout. You need a
kernel that sets non-exec stack by default and respects PT_GNU_STACK
program header.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply
* Re: PCI driver on EB8347
From: Rajan Rai @ 2006-08-13 4:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: Gala Kumar K.-galak, Liu Dave-r63238, linuxppc-embedded
In-Reply-To: <D9682BD5-FBDF-4D6C-BC82-6EF375DB6F46@kernel.crashing.org>
Kumar, Liu
I was able to resolve problem. Problem was in PCI card
firmware and not in Linux Kernel or driver.
Thanks for your help.
Regards,
-Rajan
Kumar Gala wrote:
>
> On Aug 12, 2006, at 7:34 AM, Rajan Rai wrote:
>
>>
>>
>> Thanks IRQ problem is resolved. As pointed out it was
>> problem with IRQ IDSEL mapping. Mapping needs to be different on Eval
>> board I'm using and our custom design. But my driver is still not
>> working on our custom design. PCI device doesn't receive any messages
>> from MPC8347 on our custom design mother board which uses pci-bridge
>> where as it works fine on Eval board which doesn't use PCI bridge.
>>
>> I guess problem lies at the kernel level and
>> not the driver. Any tips apart from IDSEL IRQ settings at kernel
>> level what else I need to change when I move from 1 mother board to
>> another. My PCI devices do get base address 0 and 1 allocated
>> properly by the OS. But when I try to write any messages on those
>> addresses PCI device doesn't see them
>
> Is the bridge getting configured correctly? An lspci output would be
> helpful from your system with the P2P bridge.
>
> - kumar
>
>
^ permalink raw reply
* Re: [PATCH 3/6] ehea: queue management
From: Anton Blanchard @ 2006-08-13 14:44 UTC (permalink / raw)
To: Thomas Klein
Cc: Thomas Klein, Jan-Bernd Themann, roland, netdev, linux-kernel,
Christoph Raisch, linux-ppc, Marcus Eder
In-Reply-To: <44DE03B0.1060607@de.ibm.com>
Hi,
> I agree, stubbs were removed.
Thanks.
What is going to be done about the debug infrastructure in the ehea
driver? The entry and exit traces really need to go, and any other debug
you think is important to users needs to go into debugfs or something
similar.
I see a similar issue in the ehca driver that I am in the middle of
reviewing.
Anton
^ permalink raw reply
* Power Management Support
From: E B @ 2006-08-13 16:33 UTC (permalink / raw)
To: linuxppc-embedded
Hi Guys,
I'm trying to add to my board a cpu power management
support.
I'm using IBM 750GX.
I red about the ACPI mechanism.Is this type of cpu
support it ? I want to add the kernel some mechanism
that enable to chose which state to put the cpu
(SLEEP,NAP,DOZE),is it possible(recommended) or should
the Linux do it differently ?
Thanks...
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: PowerPC paxtest results w/ gcc-4.1
From: Hollis Blanchard @ 2006-08-13 16:45 UTC (permalink / raw)
To: Albert Cahalan; +Cc: linuxppc-dev, debian-powerpc, Paul Mackerras
In-Reply-To: <787b0d920608122111p79f29d74r600382658599cd63@mail.gmail.com>
On Sun, 2006-08-13 at 00:11 -0400, Albert Cahalan wrote:
>
> On 8/12/06, Paul Mackerras <paulus@samba.org> wrote:
> > Albert Cahalan writes:
> >
> > > VM_STACK_DEFAULT_FLAGS32 is wrong. A fail-safe
> > > default is important for security. If gcc on PowerPC ever
> > > does generate code which puts trampolines on the stack,
> > > then that can be fixed by converting to legal C code or
> > > by adding the fragile marking to the defective executables.
> > > Did gcc ever generate such code on PowerPC? If not,
> > > then there is no reason to ever allow an executable stack.
> >
> > I believe it did for nested procedures in C.
>
> I just disassembled libgcc. You're right. Eeeeeew.
> I filed a bug describing two better methods for this.
URL?
-Hollis
^ permalink raw reply
* Re: PowerPC paxtest results w/ gcc-4.1
From: Albert Cahalan @ 2006-08-13 18:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <17630.27174.711916.643790@cargo.ozlabs.ibm.com>
On 8/12/06, Paul Mackerras <paulus@samba.org> wrote:
> Of course, that won't make all that much difference on your Cube,
> because the G4 CPU doesn't have hardware support for non-executable
> pages (any readable page is executable).
I now have an evil grin, and a kernel that prevents
execution from the stack. It passes that one part
of paxtest now.
If the -msecure-plt actually did something (it's a nop
according to md5sum) and the executable mappings
didn't share with other ones, I'd have it all protected.
Signed-off-by: Albert Cahalan
---------
--- linux-2.6.17-rc5/arch/powerpc/kernel/head_32.S 2006-05-24
21:50:17.000000000 -0400
+++ linux-17rc5-secure/arch/powerpc/kernel/head_32.S 2006-08-13
10:48:38.000000000 -0400
@@ -1182,7 +1182,7 @@
_GLOBAL(set_context)
mulli r3,r3,897 /* multiply context by skew factor */
rlwinm r3,r3,4,8,27 /* VSID = (context & 0xfffff) << 4 */
- addis r3,r3,0x6000 /* Set Ks, Ku bits */
+ addis r3,r3,0x7000 /* Set Ks, Ku, N bits */
li r0,NUM_USER_SEGMENTS
mtctr r0
--- linux-2.6.17-rc5/arch/powerpc/mm/fault.c 2006-05-24
21:50:17.000000000 -0400
+++ linux-17rc5-secure/arch/powerpc/mm/fault.c 2006-08-13
19:17:22.000000000 -0400
@@ -134,8 +134,8 @@
* bits we are interested in. But there are some bits which
* indicate errors in DSISR but can validly be set in SRR1.
*/
- if (trap == 0x400)
- error_code &= 0x48200000;
+ if (is_exec)
+ error_code &= 0x58200000;
else
is_write = error_code & DSISR_ISSTORE;
#else
@@ -242,7 +242,7 @@
good_area:
code = SEGV_ACCERR;
#if defined(CONFIG_6xx)
- if (error_code & 0x95700000)
+ if (error_code & 0x85700000)
/* an error such as lwarx to I/O controller space,
address matching DABR, eciwx, etc. */
goto bad_area;
@@ -258,12 +258,24 @@
#endif /* CONFIG_8xx */
if (is_exec) {
+ if (!(vma->vm_flags & VM_EXEC)) {
+#if 0
+ static __typeof__(jiffies) oldjif;
+ static int count;
+ if(count++ < 5)
+ printk(KERN_CRIT "fuckup @ %08lx with trap
0x%x code %08lx by %s\n",
+ address, trap, error_code, current->comm);
+ if(jiffies/(HZ*15) != oldjif/(HZ*15)) {
+ oldjif = jiffies;
+ count = 0;
+ }
+#endif
+ goto bad_area;
+ }
#ifdef CONFIG_PPC64
/* protection fault */
if (error_code & DSISR_PROTFAULT)
goto bad_area;
- if (!(vma->vm_flags & VM_EXEC))
- goto bad_area;
#endif
#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
pte_t *ptep;
@@ -291,6 +303,27 @@
pte_unmap_unlock(ptep, ptl);
}
#endif
+#if !defined(CONFIG_4xx) && !defined(CONFIG_BOOKE) && !defined(CONFIG_PPC64)
+ if (!(error_code & 0x10000000))
+ goto survive;
+ /* It was an ISI exception with SRR1 bit 3 set.
+ * We have no-execute bits in the 256 MiB segments.
+ * We sometimes take faults to turn the bits on.
+ * Faults happen when the user executes from guarded mem,
+ * no-execute segment, or (extinct) direct-store segment.
+ * The segment-related faults happen first. */
+ unsigned segreg;
+ __asm__ __volatile__("mfsrin %0,%1":"=r"(segreg):"r"(address));
+ /* if current segment is no-execute but not direct-store */
+ if (segreg>>28==7) {
+ /* clear the N bit to make it executable */
+ segreg &= 0x6fffffff;
+ __asm__ __volatile__("mtsrin
%0,%1"::"r"(segreg),"r"(address));
+ /* TODO: as this one goes executable, make
other segments not */
+ up_read(&mm->mmap_sem);
+ return 0;
+ }
+#endif
/* a write */
} else if (is_write) {
if (!(vma->vm_flags & VM_WRITE))
@@ -300,7 +333,7 @@
/* protection fault */
if (error_code & 0x08000000)
goto bad_area;
- if (!(vma->vm_flags & (VM_READ | VM_EXEC)))
+ if (!(vma->vm_flags & (VM_READ | VM_EXEC))) /* VM_EXEC
wrong for ppc32? */
goto bad_area;
}
--- linux-2.6.17-rc5/include/asm-powerpc/page.h 2006-05-24
21:50:17.000000000 -0400
+++ linux-17rc5-secure/include/asm-powerpc/page.h 2006-08-13
11:58:25.000000000 -0400
@@ -90,6 +90,9 @@
#define VM_DATA_DEFAULT_FLAGS64 (VM_READ | VM_WRITE | \
VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
+#define VM_STACK_DEFAULT_FLAGS (VM_READ | VM_WRITE | \
+ VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
+
#ifdef __powerpc64__
#include <asm/page_64.h>
#else
^ permalink raw reply
* Re: PowerPC paxtest results w/ gcc-4.1
From: Albert Cahalan @ 2006-08-13 18:59 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev, debian-powerpc, Paul Mackerras
In-Reply-To: <1155487501.18244.0.camel@diesel>
On 8/13/06, Hollis Blanchard <hollis@penguinppc.org> wrote:
> On Sun, 2006-08-13 at 00:11 -0400, Albert Cahalan wrote:
> >
> > On 8/12/06, Paul Mackerras <paulus@samba.org> wrote:
> > > Albert Cahalan writes:
> > >
> > > > VM_STACK_DEFAULT_FLAGS32 is wrong. A fail-safe
> > > > default is important for security. If gcc on PowerPC ever
> > > > does generate code which puts trampolines on the stack,
> > > > then that can be fixed by converting to legal C code or
> > > > by adding the fragile marking to the defective executables.
> > > > Did gcc ever generate such code on PowerPC? If not,
> > > > then there is no reason to ever allow an executable stack.
> > >
> > > I believe it did for nested procedures in C.
> >
> > I just disassembled libgcc. You're right. Eeeeeew.
> > I filed a bug describing two better methods for this.
>
> URL?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382746
^ permalink raw reply
* Re: [RFC] Debugging with a HW probe.
From: Jimi Xenidis @ 2006-08-13 19:10 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20060807230606.GC11805@pb15.lixom.net>
On Aug 7, 2006, at 7:06 PM, Olof Johansson wrote:
> > --- a/include/asm-powerpc/xmon.h
> > +++ b/include/asm-powerpc/xmon.h
> > @@ -8,5 +8,12 @@ extern int xmon(struct pt_regs *excp);
> > extern void xmon_printf(const char *fmt, ...);
> > extern void xmon_init(int);
> >
> > +/*
> > + * Support Processor Attention Instruction introduced in POWER
> > + * architecture processors as of RS64, tho may not be supported by
> > + * POWER 3.
> > + */
> > +#define ATTN() asm volatile(".long 0x00000200; nop")
>
> At least my toolchain understands "attn ; nop"?
looks like it was added in 2003:
2003-06-10 Gary Hade <garyhade@us.ibm.com>
Alan Modra <amodra@bigpond.net.au>
* ppc-opc.c (DQ, RAQ, RSQ, RTQ): Define.
(insert_dq, extract_dq, insert_raq, insert_rtq, insert_rsq): New.
(powerpc_opcodes): Add "attn", "lq" and "stq".
am happy to put in symbolically.
^ permalink raw reply
* Take 2: [RFC] Debugging with a HW probe.
From: Jimi Xenidis @ 2006-08-13 19:16 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060807230606.GC11805@pb15.lixom.net>
A rework of the original patch, some on and off list comments had
suggested that this be a generic service, and to make it very hard
to unintentionally turn it on. I fact we should make sure that the
feature is indeed turned off.
Any suggestions on how to operate on the HID bits of all CPUs based on
the value of the config _and_ 'hw_probe_enabled' would be welcom.
I'd also like to wait for Olof's:
http://ozlabs.org/pipermail/linuxppc-dev/2006-August/025024.html
patch to make it to the tree (or not).
Signed-off-by: Jimi Xenidis <jimix@watson.ibm.com>
---
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index e29ef77..bc4cdf9 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -61,6 +61,17 @@ config KGDB_CONSOLE
over the gdb stub.
If unsure, say N.
+config ENABLE_HW_PROBE
+ bool "Allow instructions that contact a hardware probe (dangerous)"
+ depends on PPC64
+ help
+ If you enable this AND you add "hwprobe" to the cmdline, the
+ processor will enable instructions that contact the hardware
+ probe. These instructions ca be used in all processor modes
+ _including_ user mode and are only useful for kernel
+ development and debugging. DO NOT enable this unless you
+ plan to use it.
+
config XMON
bool "Include xmon kernel debugger"
depends on DEBUGGER && !PPC_ISERIES
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index bf2005b..02c5b83 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -68,6 +68,9 @@ int __initdata iommu_is_off;
int __initdata iommu_force_on;
unsigned long tce_alloc_start, tce_alloc_end;
#endif
+#ifdef CONFIG_ENABLE_HW_PROBE
+int hw_probe_enabled;
+#endif
typedef u32 cell_t;
@@ -693,6 +696,11 @@ #ifdef CONFIG_PPC64
if (of_get_flat_dt_prop(node, "linux,iommu-force-on", NULL) != NULL)
iommu_force_on = 1;
#endif
+#ifdef CONFIG_HW_PROBE_ENABLE
+ if (of_get_flat_dt_prop(node, "linux,hw-probe-enable", NULL) != NULL) {
+ hw_probe_enabled = 1;
+ DBG("HW Probe will be enabled\n");
+#endif
/* mem=x on the command line is the preferred mechanism */
lprop = of_get_flat_dt_prop(node, "linux,memory-limit", NULL);
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 90972ef..26428de 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -587,6 +587,14 @@ #ifdef CONFIG_PPC64
RELOC(iommu_force_on) = 1;
}
#endif
+#ifdef CONFIG_HW_PROBE_ENABLE
+ opt = strstr(RELOC(prom_cmd_line), RELOC("hwprobe"));
+ if (opt) {
+ prom_printf("WARNING! HW Probe will be activated!\n");
+ prom_setprop(_prom->chosen, "/chosen",
+ "linux,hw-probe-enable", NULL, 0);
+ }
+#endif
}
#ifdef CONFIG_PPC_PSERIES
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 179b10c..51a1e4e 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -189,7 +189,12 @@ #endif
dd dump double values\n\
dr dump stream of raw bytes\n\
e print exception information\n\
- f flush cache\n\
+ f flush cache\n"
+#ifdef CONFIG_ENABLE_HW_PROBE
+ "\
+ H Contact hardware probe, if available\n"
+#endif
+ "\
la lookup symbol+offset of specified address\n\
ls lookup address of specified symbol\n\
m examine/change memory\n\
@@ -217,6 +222,18 @@ #endif
zh halt\n"
;
+#ifdef CONFIG_ENABLE_HW_PROBE
+/* try to keep this funtion from being inlined so its easier to move
+ * around the ATTN instruction */
+extern int hw_probe_enabled;
+static noinline void xmon_hw_probe(void)
+{
+ if (!hw_probe_enabled)
+ return;
+ ATTN();
+}
+#endif
+
static struct pt_regs *xmon_regs;
static inline void sync(void)
@@ -819,6 +836,11 @@ #endif /* CONFIG_SMP */
if (cpu_cmd())
return 0;
break;
+#ifdef CONFIG_ENABLE_HW_PROBE
+ case 'H':
+ xmon_hw_probe();
+ break;
+#endif
case 'z':
bootcmds();
break;
diff --git a/include/asm-powerpc/reg.h b/include/asm-powerpc/reg.h
index cf73475..478097e 100644
--- a/include/asm-powerpc/reg.h
+++ b/include/asm-powerpc/reg.h
@@ -207,6 +207,13 @@ #define SPRN_EAR 0x11A /* External Addr
#define SPRN_HASH1 0x3D2 /* Primary Hash Address Register */
#define SPRN_HASH2 0x3D3 /* Secondary Hash Address Resgister */
#define SPRN_HID0 0x3F0 /* Hardware Implementation Register 0 */
+#ifdef __ASSEMBLY__
+#define HID0_QATTN (1<<35) /* Sup. Proc. attn insn all threads */
+#define HID0_ATTN (1<<32) /* Sup. Proc. attn insn */
+#else
+#define HID0_QATTN (1UL<<35) /* Sup. Proc. attn insn all threads */
+#define HID0_ATTN (1UL<<32) /* Sup. Proc. attn insn */
+#endif
#define HID0_EMCP (1<<31) /* Enable Machine Check pin */
#define HID0_EBA (1<<29) /* Enable Bus Address Parity */
#define HID0_EBD (1<<28) /* Enable Bus Data Parity */
@@ -641,6 +648,13 @@ extern void ppc64_runlatch_off(void);
extern unsigned long scom970_read(unsigned int address);
extern void scom970_write(unsigned int address, unsigned long value);
+/*
+ * Support Processor Attention Instruction instroduced in POWER
+ * architecture processors as of RS64, tho may not be supported by
+ * POWER 3.
+ */
+#define ATTN() asm volatile("attn; nop")
+
#else
#define ppc64_runlatch_on()
#define ppc64_runlatch_off()
^ permalink raw reply related
* Re: [PATCH 4/6] ehea: header files
From: Michael Ellerman @ 2006-08-14 3:20 UTC (permalink / raw)
To: Anton Blanchard
Cc: Thomas Klein, netdev, linux-kernel, Christoph Raisch, linux-ppc,
Marcus Eder
In-Reply-To: <20060811214020.GG479@krispykreme>
[-- Attachment #1: Type: text/plain, Size: 710 bytes --]
On Sat, 2006-08-12 at 07:40 +1000, Anton Blanchard wrote:
> Hi,
>
> > drivers/net/ehea/ehea.h | 452
>
> > +#define EHEA_DRIVER_NAME "IBM eHEA"
>
> You are using this for ethtool get_drvinfo. Im not sure if it should
> match the module name, and I worry about having a space in the name. Any
> ideas on what we should be doing here?
I believe it must match the module name. It also might be nice to call
it "DRV_NAME" like most other network drivers do.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* [PATCH] no-execute -- please test
From: Albert Cahalan @ 2006-08-14 3:20 UTC (permalink / raw)
To: linuxppc-dev, debian-powerpc
This kernel patch implements no-execute protection (like x86 "NX bit")
for the Mac G2, Mac G3, Mac G4, and other systems running 32-bit
PowerPC processors in the 6xx, 7xx, and 7xxx families.
As given, it usually protects from executing code on the stack.
This has to do with the typical buffer overflow exploit.
I'm running this now on a Mac G4, including X, with no ill effect.
If you want to see messages when an app violates this, change
the "#if 0" to "#if 1". I get no messages except when I run
paxtest to verify that the protection works.
If you want heap protection, change VM_DATA_DEFAULT_FLAGS32
in include/asm-powerpc/page.h to be like VM_STACK_DEFAULT_FLAGS.
I'd love to hear if anybody can get X to start with this change.
For me (Xorg w/ ATI) a module load fails. Probably because of
poor address space layout, paxtest shows no improvement with this.
Still, I'd love to hear if X (perhaps framebuffer and no GL) works
OK with this extra change.
Apply like this:
cd directory-with-kernel-source
patch -p1 -s -E -l < file-containing-this-email
--- linux-2.6.17-rc5/arch/powerpc/kernel/head_32.S 2006-05-24
21:50:17.000000000 -0400
+++ linux-17rc5-secure/arch/powerpc/kernel/head_32.S 2006-08-13
10:48:38.000000000 -0400
@@ -1182,7 +1182,7 @@
_GLOBAL(set_context)
mulli r3,r3,897 /* multiply context by skew factor */
rlwinm r3,r3,4,8,27 /* VSID = (context & 0xfffff) << 4 */
- addis r3,r3,0x6000 /* Set Ks, Ku bits */
+ addis r3,r3,0x7000 /* Set Ks, Ku, N bits */
li r0,NUM_USER_SEGMENTS
mtctr r0
--- linux-2.6.17-rc5/arch/powerpc/mm/fault.c 2006-05-24
21:50:17.000000000 -0400
+++ linux-17rc5-secure/arch/powerpc/mm/fault.c 2006-08-13
19:17:22.000000000 -0400
@@ -134,8 +134,8 @@
* bits we are interested in. But there are some bits which
* indicate errors in DSISR but can validly be set in SRR1.
*/
- if (trap == 0x400)
- error_code &= 0x48200000;
+ if (is_exec)
+ error_code &= 0x58200000;
else
is_write = error_code & DSISR_ISSTORE;
#else
@@ -242,7 +242,7 @@
good_area:
code = SEGV_ACCERR;
#if defined(CONFIG_6xx)
- if (error_code & 0x95700000)
+ if (error_code & 0x85700000)
/* an error such as lwarx to I/O controller space,
address matching DABR, eciwx, etc. */
goto bad_area;
@@ -258,12 +258,24 @@
#endif /* CONFIG_8xx */
if (is_exec) {
+ if (!(vma->vm_flags & VM_EXEC)) {
+#if 0
+ static __typeof__(jiffies) oldjif;
+ static int count;
+ if(count++ < 5)
+ printk(KERN_CRIT "fuckup @ %08lx with trap
0x%x code %08lx by %s\n",
+ address, trap, error_code, current->comm);
+ if(jiffies/(HZ*15) != oldjif/(HZ*15)) {
+ oldjif = jiffies;
+ count = 0;
+ }
+#endif
+ goto bad_area;
+ }
#ifdef CONFIG_PPC64
/* protection fault */
if (error_code & DSISR_PROTFAULT)
goto bad_area;
- if (!(vma->vm_flags & VM_EXEC))
- goto bad_area;
#endif
#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
pte_t *ptep;
@@ -291,6 +303,27 @@
pte_unmap_unlock(ptep, ptl);
}
#endif
+#if !defined(CONFIG_4xx) && !defined(CONFIG_BOOKE) && !defined(CONFIG_PPC64)
+ if (!(error_code & 0x10000000))
+ goto survive;
+ /* It was an ISI exception with SRR1 bit 3 set.
+ * We have no-execute bits in the 256 MiB segments.
+ * We sometimes take faults to turn the bits on.
+ * Faults happen when the user executes from guarded mem,
+ * no-execute segment, or (extinct) direct-store segment.
+ * The segment-related faults happen first. */
+ unsigned segreg;
+ __asm__ __volatile__("mfsrin %0,%1":"=r"(segreg):"r"(address));
+ /* if current segment is no-execute but not direct-store */
+ if (segreg>>28==7) {
+ /* clear the N bit to make it executable */
+ segreg &= 0x6fffffff;
+ __asm__ __volatile__("mtsrin
%0,%1"::"r"(segreg),"r"(address));
+ /* TODO: as this one goes executable, make
other segments not */
+ up_read(&mm->mmap_sem);
+ return 0;
+ }
+#endif
/* a write */
} else if (is_write) {
if (!(vma->vm_flags & VM_WRITE))
@@ -300,7 +333,7 @@
/* protection fault */
if (error_code & 0x08000000)
goto bad_area;
- if (!(vma->vm_flags & (VM_READ | VM_EXEC)))
+ if (!(vma->vm_flags & (VM_READ | VM_EXEC))) /* VM_EXEC
wrong for ppc32? */
goto bad_area;
}
--- linux-2.6.17-rc5/include/asm-powerpc/page.h 2006-05-24
21:50:17.000000000 -0400
+++ linux-17rc5-secure/include/asm-powerpc/page.h 2006-08-13
11:58:25.000000000 -0400
@@ -90,6 +90,9 @@
#define VM_DATA_DEFAULT_FLAGS64 (VM_READ | VM_WRITE | \
VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
+#define VM_STACK_DEFAULT_FLAGS (VM_READ | VM_WRITE | \
+ VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
+
#ifdef __powerpc64__
#include <asm/page_64.h>
#else
^ permalink raw reply
* RE: PCI DMA_MR Problem
From: Liu Dave-r63238 @ 2006-08-14 3:53 UTC (permalink / raw)
To: jimmy liu, linuxppc-embedded
In-Reply-To: <20060811135746.68402.qmail@web53115.mail.yahoo.com>
The memory map configuration registers is little-endain. Be careful this
Please byte swap this
-Dave=20
>=20
> I got a problem when I set the pci dmamr for MPC8250 for DMA=20
> PCI transfering data on linux kernel 2.6.17.
> When I set the values for the pci_dmamr registers, then print=20
> the register values back, some bits can not be set. Did=20
> anybody know what are the problem, or I have to set other stuff.
>=20
> Thanks.
>=20
> The code like this:
>=20
> volatile cpm2_map_t *immap =3D cpm2_immr;
> immap->im_pci.pci_dmamr0 =3D 0x0042b00c;
> immap->im_pci.pci_dmamr1 =3D 0x0042b00c;
> immap->im_pci.pci_dmamr2 =3D 0x0042b00c;
> immap->im_pci.pci_dmamr3 =3D 0x0042b00c;
>=20
> printk("DMA0 MR =3D 0x%08x\n",
> immap->im_pci.pci_dmamr0);
> printk("DMA1 MR (0x%08x) =3D 0x%08x\n",
> immap->im_pci.pci_dmamr1);
> printk("DMA2 MR (0x%08x) =3D 0x%08x\n",
> immap->im_pci.pci_dmamr2);
> printk("DMA3 MR (0x%08x) =3D 0x%08x\n",
> immap->im_pci.pci_dmamr3);
>=20
> The results are following:
> DMA0 MR (0xf0010500) =3D 0x0040b000
> DMA1 MR (0xf0010580) =3D 0x0040b000
> DMA2 MR (0xf0010600) =3D 0x0040b000
> DMA3 MR (0xf0010680) =3D 0x0040b000
>=20
>=20
>=20
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection=20
> around http://mail.yahoo.com=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
^ permalink raw reply
* Re: [PATCH] no-execute -- please test
From: Paul Mackerras @ 2006-08-14 4:00 UTC (permalink / raw)
To: Albert Cahalan; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <787b0d920608132020q4ad2b5c2y49e25ca7ecc33536@mail.gmail.com>
Albert Cahalan writes:
> This kernel patch implements no-execute protection (like x86 "NX bit")
> for the Mac G2, Mac G3, Mac G4, and other systems running 32-bit
> PowerPC processors in the 6xx, 7xx, and 7xxx families.
I'd be interested in benchmark comparisons with/without this patch, if
anyone cares to run lmbench, kernbench etc. with and without... If
the performance impact is minimal I'll be happy to apply it. If the
impact is noticeable then it might need to be selectable with a config
option.
Paul.
^ permalink raw reply
* Re: [PATCH] no-execute -- please test
From: Paul Mackerras @ 2006-08-14 4:02 UTC (permalink / raw)
To: Albert Cahalan; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <787b0d920608132020q4ad2b5c2y49e25ca7ecc33536@mail.gmail.com>
Albert Cahalan writes:
> If you want heap protection, change VM_DATA_DEFAULT_FLAGS32
> in include/asm-powerpc/page.h to be like VM_STACK_DEFAULT_FLAGS.
> I'd love to hear if anybody can get X to start with this change.
In general I would expect dynamically-linked programs to fail unless
you compile everything with gcc -msecure-plt.
Paul.
^ permalink raw reply
* Re: [PATCH] no-execute -- please test
From: Albert Cahalan @ 2006-08-14 4:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <17631.62940.63888.908937@cargo.ozlabs.ibm.com>
On 8/14/06, Paul Mackerras <paulus@samba.org> wrote:
> Albert Cahalan writes:
>
> > If you want heap protection, change VM_DATA_DEFAULT_FLAGS32
> > in include/asm-powerpc/page.h to be like VM_STACK_DEFAULT_FLAGS.
> > I'd love to hear if anybody can get X to start with this change.
>
> In general I would expect dynamically-linked programs to fail unless
> you compile everything with gcc -msecure-plt.
I wouldn't, unless they are also buggy. The PLT should be
marked for full rwx permissions. Enforcing W^X is another
matter entirely of course.
For me, X is the only observed failure with that extra change.
I successfully got to a console, did a bit of exploring at the
command prompt, watched X go to the stiple background
before shutting down in an orderly fashion, and rebooted.
Perhaps do_brk could get a third argument to specify the
caller, so that VM_EXEC could be cleared for some callers.
Then again, pretending to be a Vista developer, I could just
have the kernel recognize the buggy X server.
Other notes:
For maximum benefit, shared objects should be built such
that the executable part can be mapped without any
relation to the other parts. The next best thing would be
to have the executable parts start 256 MiB above where
the other parts start. This allows randomization to be
added without causing loss of no-execute capability.
We need a new gcc default: -msecure-plt -pie -fPIE
^ permalink raw reply
* Re: [PATCH] no-execute -- please test
From: Albert Cahalan @ 2006-08-14 4:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <17631.62819.24167.555967@cargo.ozlabs.ibm.com>
On 8/14/06, Paul Mackerras <paulus@samba.org> wrote:
> Albert Cahalan writes:
>
> > This kernel patch implements no-execute protection (like x86 "NX bit")
> > for the Mac G2, Mac G3, Mac G4, and other systems running 32-bit
> > PowerPC processors in the 6xx, 7xx, and 7xxx families.
>
> I'd be interested in benchmark comparisons with/without this patch, if
> anyone cares to run lmbench, kernbench etc. with and without... If
> the performance impact is minimal I'll be happy to apply it. If the
> impact is noticeable then it might need to be selectable with a config
> option.
There are a couple optimizations that can be done if needed.
The first is to avoid taking the initial fault on the segment
which contains the instruction pointer.
The second is to avoid cache or TLB invalidates or flushes
in certain circumstances. OpenBSD developers report that
this type of optimization is of great benefit on sparc and ppc.
It's an optimization than is only valid when no-execute is
in use, so the performance effects go both ways.
^ permalink raw reply
* Re: [PATCH 4/6] ehea: header files
From: Jan-Bernd Themann @ 2006-08-14 6:19 UTC (permalink / raw)
To: michael
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Anton Blanchard, Marcus Eder
In-Reply-To: <1155525611.7807.4.camel@localhost.localdomain>
Michael Ellerman wrote:
> On Sat, 2006-08-12 at 07:40 +1000, Anton Blanchard wrote:
>> Hi,
>>
>>> drivers/net/ehea/ehea.h | 452
>>> +#define EHEA_DRIVER_NAME "IBM eHEA"
>> You are using this for ethtool get_drvinfo. Im not sure if it should
>> match the module name, and I worry about having a space in the name. Any
>> ideas on what we should be doing here?
>
> I believe it must match the module name. It also might be nice to call
> it "DRV_NAME" like most other network drivers do.
>
> cheers
>
We rename EHEA_DRIVER_NAME to DRV_NAME (and EHEA_DRIVER_VERSION
to DRV_VERSION) and assign "ehea" to it
Jan-Bernd
^ permalink raw reply
* Re: [PATCH] no-execute -- please test
From: Andreas Schwab @ 2006-08-14 8:46 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Albert Cahalan, linuxppc-dev, debian-powerpc
In-Reply-To: <17631.62940.63888.908937@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Albert Cahalan writes:
>
>> If you want heap protection, change VM_DATA_DEFAULT_FLAGS32
>> in include/asm-powerpc/page.h to be like VM_STACK_DEFAULT_FLAGS.
>> I'd love to hear if anybody can get X to start with this change.
>
> In general I would expect dynamically-linked programs to fail unless
> you compile everything with gcc -msecure-plt.
X (before X.org 7) does it's own module loading that cannot cope with a
non-executable heap. X.org 7, on the other hand, uses dlopen now and
should work fine.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: XUPV2P, Kernel 2.6.17 boot problem
From: Benjamin Heyne @ 2006-08-14 9:10 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-embedded
In-Reply-To: <31155357445643c98694.1714636915.miltonm@bga.com>
And so it came to pass, that on Fri, 11 Aug 2006 23:37:25 -0500
Milton Miller <miltonm@bga.com> wrote as thus:
> On Mon Aug 7 2006 04:46:43 AM CDT, Benjamin Heyne wrote:
> > Peter Korsgaard <jacmet@sunsite.dk> wrote as thus:
> > > >>>>> "David" == David H Lynch <dhlii@dlasys.net>
> > > David> Have you tried 2.6.18.x to see if your stuff works with it
> > > David> ?
> > >
> > > Yes, 2.6.18-rc3 + my zlib fix
> > > (http://thread.gmane.org/gmane.linux.kernel/428436) or -rc4 once it
> > > hits kernel.org works fine on my v2p-based board.
> >
> > Well, unfortunately I am still getting the inflate error
> > as soon as the image grows >2MB (about). Have you tried with
> > images of this size? If the image is smaller, everything works
> > fine...
>
> My first reaction when I saw this thread was that you didn't allocate
> something in memory and overlapped something. However, looking
> at your original post again, I think your kernel is growing larger than
> 4MB, which is the link address of the zImage. This is based on the
> kernel is decompressed to address 0 in
> ppc/boot/simple/misc-embedded.c, and a 50% compression factor
> and 2MB compressed image.
>
> You can look at the file size of vmlinux to see if this is close.
>
> milton
Well - That's exactly the case. But looking into misc-embedded.c, I noticed
that the load address for gunzip is fixed to 0x400000...shouldn't this
be dependent on CONFIG_BOOT_LOAD_BOOL and CONFIG_BOOT_LOAD?
I've changed the line to
#ifdef CONFIG_BOOT_LOAD_BOOL
gunzip(0, CONFIG_BOOT_LOAD, zimage_start, &zimage_size);
#else
gunzip(0, 0x400000, zimage_start, &zimage_size);
#endif
and now it seems to work fine for big images (if CONFIG_BOOT_LOAD
is set large enough of course...) - which wasn't the case before.
Best regards
--
Benjamin Heyne
^ permalink raw reply
* Re: [PATCH] no-execute -- please test
From: Michel Dänzer @ 2006-08-14 9:19 UTC (permalink / raw)
To: Albert Cahalan; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <787b0d920608132020q4ad2b5c2y49e25ca7ecc33536@mail.gmail.com>
On Sun, 2006-08-13 at 23:20 -0400, Albert Cahalan wrote:
>
> If you want heap protection, change VM_DATA_DEFAULT_FLAGS32
> in include/asm-powerpc/page.h to be like VM_STACK_DEFAULT_FLAGS.
> I'd love to hear if anybody can get X to start with this change.
> For me (Xorg w/ ATI) a module load fails.
Which versions of the X server and driver, and which module fails to
load exactly how? As of X.Org 6.9, the X server no longer uses a custom
module loader but just dlopen and friends.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: [PATCH 1/6] ehea: interface to network stack
From: Jörn Engel @ 2006-08-14 11:26 UTC (permalink / raw)
To: Anton Blanchard
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <20060811205624.GE479@krispykreme>
On Sat, 12 August 2006 06:56:24 +1000, Anton Blanchard wrote:
>
> > +
> > + skb_index = ((index - i
> > + + port_res->skb_arr_sq_len)
> > + % port_res->skb_arr_sq_len);
>
> This is going to force an expensive divide. Its much better to change
> this to the simpler and quicker:
>
> i++;
> if (i > max)
> i = 0;
Is a conditional cheaper than a divide? In case of a misprediction I
would assume it to be significantly slower and I don't know the ratio
of mispredictions for this branch.
Jörn
--
Victory in war is not repetitious.
-- Sun Tzu
^ permalink raw reply
* U-boot and 2.6 kernel
From: pranav choudhary @ 2006-08-14 11:35 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 723 bytes --]
Hi,
I am using an old version of u-boot and 2.6.13 kernel on IXDP425 hardware. The booting process stalls. After a little debugging i found that the booting stalls sfter call to jump() [__FUNCTION__ = CON_Run_Firmware, __FILE__ == conleaf.c. It seems that the correct image is not copied to KERNEL_RUN_ADDRESS.
I found another thread that talked of old u-boot and 2.6 kernels but i could not make out anything useful from it. Can someone please give me some pointers on where to start debugging...
---
dimensions_infinite@yahoo.com
Pranav Choudhary
Software Engineer
Net Devices India Pvt. Ltd
Bangalore
---------------------------------
How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone call rates.
[-- Attachment #2: Type: text/html, Size: 1036 bytes --]
^ permalink raw reply
* RE: PowerPC paxtest results w/ gcc-4.1
From: Matt Sealey @ 2006-08-14 11:50 UTC (permalink / raw)
To: 'Paul Mackerras', 'Albert Cahalan'
Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <17630.27174.711916.643790@cargo.ozlabs.ibm.com>
> Of course, that won't make all that much difference on your
> Cube, because the G4 CPU doesn't have hardware support for
> non-executable pages (any readable page is executable)
I don't think this is true?
Book I compatible PowerPC's have had a "no-executable" bit in
the page protection flags since the dark ages.. see page 7-38
and 7-39 of the 'Programming Environments Manual for 32-Bit
Microprocessors'.. this document predates even the G3.
As far as the documentation goes, you can make the page
readable and writable to the LSU, but the N bit causes the
instruction fetch to cause a machine check. That's pretty
"not-executable" to me at least :)
--
Matt Sealey <matt@genesi-usa.com>
Manager, Genesi, Developer Relations
^ permalink raw reply
* RE: PowerPC paxtest results w/ gcc-4.1
From: Matt Sealey @ 2006-08-14 12:17 UTC (permalink / raw)
To: 'Albert Cahalan', 'Paul Mackerras'
Cc: linuxppc-dev, 'debian-powerpc'
In-Reply-To: <787b0d920608122111p79f29d74r600382658599cd63@mail.gmail.com>
> That looks like a 64-bit system, which doesn't have the
> granularity problem anyway. 32-bit powerpc seems to be
> decent. The heap shares with the executable itself, and of
> course there is the yucky 2 GB limit.
One thing I'm curious about, has anyone EVER made a system which
actually used the 36-bit addressing on the G4?
I always wondered why such support was never in Linux but then
again if nobody connected the other 4 address lines on any PowerPC
board ever made that ran Linux, there's nothing ever to test it
on anyway. It wouldn't be any more problematic (same way as the NX
bit..) than Intel PAE support, right?
--
Matt Sealey <matt@genesi-usa.com>
Manager, Genesi, Developer Relations
^ permalink raw reply
* RE: PCI DMA_MR Problem
From: jimmy liu @ 2006-08-14 12:38 UTC (permalink / raw)
To: Liu Dave-r63238, linuxppc-embedded
In-Reply-To: <995B09A8299C2C44B59866F6391D26350CD593@zch01exm21.fsl.freescale.net>
I see.
Thanks.
Jimmy
--- Liu Dave-r63238 <DaveLiu@freescale.com> wrote:
> The memory map configuration registers is
> little-endain. Be careful this
> Please byte swap this
> -Dave
> >
> > I got a problem when I set the pci dmamr for
> MPC8250 for DMA
> > PCI transfering data on linux kernel 2.6.17.
> > When I set the values for the pci_dmamr registers,
> then print
> > the register values back, some bits can not be
> set. Did
> > anybody know what are the problem, or I have to
> set other stuff.
> >
> > Thanks.
> >
> > The code like this:
> >
> > volatile cpm2_map_t *immap = cpm2_immr;
> > immap->im_pci.pci_dmamr0 = 0x0042b00c;
> > immap->im_pci.pci_dmamr1 = 0x0042b00c;
> > immap->im_pci.pci_dmamr2 = 0x0042b00c;
> > immap->im_pci.pci_dmamr3 = 0x0042b00c;
> >
> > printk("DMA0 MR = 0x%08x\n",
> > immap->im_pci.pci_dmamr0);
> > printk("DMA1 MR (0x%08x) = 0x%08x\n",
> > immap->im_pci.pci_dmamr1);
> > printk("DMA2 MR (0x%08x) = 0x%08x\n",
> > immap->im_pci.pci_dmamr2);
> > printk("DMA3 MR (0x%08x) = 0x%08x\n",
> > immap->im_pci.pci_dmamr3);
> >
> > The results are following:
> > DMA0 MR (0xf0010500) = 0x0040b000
> > DMA1 MR (0xf0010580) = 0x0040b000
> > DMA2 MR (0xf0010600) = 0x0040b000
> > DMA3 MR (0xf0010680) = 0x0040b000
> >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam
> protection
> > around http://mail.yahoo.com
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> >
>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox