* [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
* Re: [PATCH 1/6] ehea: interface to network stack
From: Anton Blanchard @ 2006-08-14 14:38 UTC (permalink / raw)
To: Jörn Engel
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <20060814112656.GC10164@wohnheim.fh-wedel.de>
> 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.
A quick scan of the web shows 40 cycles for athlon64 idiv, and its
similarly slow on many other cpus. Even assuming you mispredict every
branch its going to be a win.
Anton
^ permalink raw reply
* Re: XUPV2P, Kernel 2.6.17 boot problem
From: Benjamin Heyne @ 2006-08-14 14:42 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-embedded
In-Reply-To: <d81b12fdf4409d827c83f98985a96822@bga.com>
And so it came to pass, that on Mon, 14 Aug 2006 09:00:33 -0500
Milton Miller <miltonm@bga.com> wrote as thus:
> >>
> >> 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
>
OK - Thanks. So replacing
gunzip(0, 0x400000, zimage_start, &zimage_size);
with
gunzip(0, CONFIG_BOOT_LOAD, zimage_start, &zimage_size);
should do the trick. Maybe we should report this to the file maintainer,
if you'd consider this to be a bug, too....
Best regards
--
Benjamin Heyne
^ permalink raw reply
* Re: [PATCH] kprobes/powerpc: Fix possible system crash during out-of-line single-stepping
From: Will Schmidt @ 2006-08-14 15:27 UTC (permalink / raw)
To: ananth; +Cc: linuxppc-dev, willschm, Paul Mackerras, Anton Blanchard
In-Reply-To: <20060811113134.GA24462@in.ibm.com>
On Fri, 2006-11-08 at 17:01 +0530, Ananth N Mavinakayanahalli wrote:
> - On archs that have no-exec support, we vmalloc() a executable scratch
> area of PAGE_SIZE and divide it up into an array of slots of maximum
> instruction size for that arch
> - On a kprobe registration, the original instruction is copied to the
> first available free slot, so if multiple kprobes are registered, chances
> are, they get contiguous slots
> - On POWER4, due to not having coherent icaches, we could hit a situation
> where a probe that is registered on one processor, is hit immediately on
> another. This second processor could have fetched the stream of text from
> the out-of-line single-stepping area *before* the probe registration
> completed, possibly due to an earlier (and a different) kprobe hit and
> hence would see stale data at the slot.
>
> Executing such an arbitrary instruction lead to a problem as reported
> in LTC bugzilla 23555.
>
> The correct solution is to call flush_icache_range() as soon as the
> instruction is copied for out-of-line single-stepping, so the correct
> instruction is seen on all processors.
>
> Thanks to Will Schmidt who tracked this down.
>
> Ananth
> ---
>
> Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Acked-by: Will Schmidt <will_schmidt@vnet.ibm.com>
-Will
^ permalink raw reply
* Re: [PATCH] no-execute -- please test
From: Albert Cahalan @ 2006-08-14 16:02 UTC (permalink / raw)
To: Michel Dänzer; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1155547172.12664.115.camel@thor.lorrainebruecke.local>
On 8/14/06, Michel D=E4nzer <michel@tungstengraphics.com> wrote:
> 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.
xorg 1:7.0.20
xserver-xorg 1:7.0.20
xserver-xorg-core 1:1.0.2-8
xserver-xorg-video-ati 1:6.5.8.0-1
Debian's aptitude program didn't complain, and I didn't do anything
like holding back a package, so the version mismatch isn't my doing.
What calls does the old X server use to allocate the memory?
Knowing the mmap() and/or mprotect() args might help to let
the old server still work.
If dlopen() doesn't need to patch up the code, W^X could be
enforced on the new X server.
^ 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