* 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
* Re: [RFC] Adding MTD to device tree
From: David Woodhouse @ 2006-08-14 12:39 UTC (permalink / raw)
To: Segher Boessenkool
Cc: arnd, Milton Miller, linuxppc-dev, linux-mtd, linuxppc-embedded
In-Reply-To: <9FC79123-7439-4800-B5B5-752AB81A6E4F@kernel.crashing.org>
On Sat, 2006-08-12 at 20:48 +0200, Segher Boessenkool wrote:
> > "Memory type devices" are specific to Linux? Doubt it. :-)
>
> The name "mtd" is.
Actually it came from PCMCIA.
--
dwmw2
^ permalink raw reply
* ehea debug output discussion
From: Jan-Bernd Themann @ 2006-08-14 12:38 UTC (permalink / raw)
To: Anton Blanchard
Cc: Thomas Klein, Jan-Bernd Themann, roland, netdev, Thomas Klein,
linux-ppc, Christoph Raisch, Marcus Eder
In-Reply-To: <20060813144400.GJ479@krispykreme>
Hi
Anton Blanchard wrote:
> 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
This is a statement for the eHEA driver:
Most of the debug outputs are redundant and we'll remove them
(EDEB_EN / EDEB_EX). We can use the standard mechanism for ethernet devices
(netif_msg_x) in most functions of ehea_main.c as we have the device struct
as a parameter available. However, some debug output mechanism is needed
where the standard mechanism does not work (functions that have no relation
to the dev struct do not have a dev parameter, for example
ehea_hcall_9arg_9ret in ehea_phyp.h)
The outcome of some internal discussions was that it is not acceptable for
our enterprise users of this type of driver on this target system to need a
recompile / reload of the driver for error analysis, so we need a mechanism
that allows us to switch on / off debug output at runtime. Therefore, we'd
introduce a stripped down version of EDEB.
Regards,
Jan-Bernd
^ permalink raw reply
* Re: [PATCH 4/6] ehea: header files
From: Jan-Bernd Themann @ 2006-08-14 12:53 UTC (permalink / raw)
To: michael
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <1155190921.9801.43.camel@localhost.localdomain>
Michael Ellerman wrote:
>> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea.h 1969-12-31 16:00:00.000000000 -0800
>> +++ kernel/drivers/net/ehea/ehea.h 2006-08-08 23:59:39.927452928 -0700
>> +
>> +#define EHEA_PAGESHIFT 12
>> +#define EHEA_PAGESIZE 4096UL
>> +#define EHEA_CACHE_LINE 128
>
> This looks like a very bad idea, what happens if you're running on a
> machine with 64K pages?
>
The EHEA_PAGESIZE define is needed for queue management to hardware side.
>> +
>> +#define EHEA_ENABLE 1
>> +#define EHEA_DISABLE 0
>
> Do you really need hash defines for 0 and 1 ? They're fairly well
> understood in C as meaning true and false.
>
removed
>> +
>> +/*
>> + * h_galpa:
>> + * for pSeries this is a 64bit memory address where
>> + * I/O memory is mapped into CPU address space
>> + */
>> +
>> +struct h_galpa {
>> + u64 fw_handle;
>> +};
>
> What is a h_galpa? And why does it need a struct if it's just a u64?
>
The eHEA chip is not PCI attached but directly connected to a proprietary
bus. Currently, we can access it by a simple 64 bit address, but this is not
true in all cases. Having a struct here allows us to encapsulate the chip
register access and to respond to changes to system hardware.
We'll change the name to h_epa meaning "ehea physical address"
>> +
>> +struct h_galpas {
>> + struct h_galpa kernel; /* kernel space accessible resource,
>> + set to 0 if unused */
>> + struct h_galpa user; /* user space accessible resource
>> + set to 0 if unused */
>> + u32 pid; /* PID of userspace galpa checking */
>> +};
>> +
>> +struct port_res_cfg {
>> + int max_entries_rcq;
>> + int max_entries_scq;
>> + int max_entries_sq;
>> + int max_entries_rq1;
>> + int max_entries_rq2;
>> + int max_entries_rq3;
>> +};
>
> Enormous structs with no comments.
>
changed
Regards,
Jan-Bernd
^ permalink raw reply
* Re: [PATCH 2/6] ehea: pHYP interface
From: Jan-Bernd Themann @ 2006-08-14 13:14 UTC (permalink / raw)
To: Anton Blanchard
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <20060811211314.GF479@krispykreme>
Hi
Anton Blanchard wrote:
> Hi,
>
>> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea_phyp.c 1969-12-31 16:00:00.000000000 -0800
>
>> +u64 ehea_h_alloc_resource_eq(const u64 hcp_adapter_handle,
> ...
>> +u64 hipz_h_reregister_pmr(const u64 adapter_handle,
> ...
>> +static inline int hcp_galpas_ctor(struct h_galpas *galpas,
>
> Be nice to have some consistent names, hipz_ and hcp_ is kind of
> cryptic.
We choose some more meaningful names and added comments to explain those.
>
>> +#define H_QP_CR_STATE_RESET 0x0000010000000000 /* Reset */
>
> Probably want ULL on here and the other 64bit constants.
>
ULL added
> Anton
Jan-Bernd
^ permalink raw reply
* Re: XUPV2P, Kernel 2.6.17 boot problem
From: Milton Miller @ 2006-08-14 14:00 UTC (permalink / raw)
To: Benjamin Heyne; +Cc: linuxppc-embedded
In-Reply-To: <20060814111014.4506dc19@bob.dt.e-technik.uni-dortmund.de>
On Aug 14, 2006, at 4:10 AM, Benjamin Heyne wrote:
> 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
>>>
>>> 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...
>>
>> I think your kernel is growing larger than
>> 4MB, which is the link address of the zImage.
>
> 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.
It shouldn't depend on CONFIG_BOOT_LOAD_BOOL. CONFIG_BOOT_LOAD is
set all the time (the question is dependent on _BOOL not the variable
and the default is used).
milton
^ permalink raw reply
* Re: PowerPC paxtest results w/ gcc-4.1
From: Kumar Gala @ 2006-08-14 14:20 UTC (permalink / raw)
To: matt
Cc: 'Albert Cahalan', linuxppc-dev, 'debian-powerpc',
'Paul Mackerras'
In-Reply-To: <000401c6bf9b$9be32ab0$99dfdfdf@bakuhatsu.net>
On Aug 14, 2006, at 7:17 AM, Matt Sealey wrote:
>
>
>> 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 believe Marvell was the only one that had chipsets that supported
the larger addressing. Looks like the TSI 108 does as well.
The 44x has some "hacks" to allow support for larger pages for IO
operations. Having struct resource now be 64-bits and some of the
page mapping functions takes pfn's make it easier to support 36-bit
physical.
> 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?
True, there is more infrastructure now to support it better. I'm not
sure how well PAE is supported in stock kernels. Go look for
discussions on the 4G/4G patches.
- kumar
^ 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