On Wed, 7 Jan 2009, malc wrote:
> On Wed, 7 Jan 2009, Benjamin Herrenschmidt wrote:
>
> >
> > > As you wish :) I've written some ad-hoc stuff in the failing path which
> > > manually triggers sysrq and then sends the klogctl output via network
> > > and here it is:
> >
> > Allright, something's
Randomize the heap.
before:
tundro2:~ # sleep 1 & cat /proc/${!}/maps | grep heap
10017000-10118000 rw-p 10017000 00:00 0 [heap]
10017000-10118000 rw-p 10017000 00:00 0 [heap]
10017000-10118000 rw-p 10017000 00:00 0
Move is_32bit_task into asm/thread_info.h, that allows us to test for
32/64bit tasks without an ugly CONFIG_PPC64 ifdef.
Signed-off-by: Anton Blanchard
---
Index: linux-2.6/arch/powerpc/include/asm/thread_info.h
===
--- linux-2.6.or
On 64bit there is a possibility our stack and mmap randomisation will put
the two close enough such that we can't expand our stack to match the ulimit
specified.
To avoid this, start the upper mmap address at 1GB + 128MB below the top of our
address space, so in the worst case we end up with the s
Randomise ELF_ET_DYN_BASE, which is used when loading position independent
executables.
Signed-off-by: Anton Blanchard
---
Index: linux-2.6/arch/powerpc/include/asm/elf.h
===
--- linux-2.6.orig/arch/powerpc/include/asm/elf.h 2
Randomise mmap start address - 8MB on 32bit and 1GB on 64bit tasks.
Until ppc32 uses the mmap.c functionality, this is ppc64 specific.
Before:
# ./test & cat /proc/${!}/maps|tail -2|head -1
f75fe000-f7fff000 rw-p f75fe000 00:00 0
f75fe000-f7fff000 rw-p f75fe000 00:00 0
f75fe000-f7fff000 rw-p f75f
Rearrange mmap.c to better match the x86 version.
Signed-off-by: Anton Blanchard
---
Index: linux-2.6/arch/powerpc/mm/mmap.c
===
--- linux-2.6.orig/arch/powerpc/mm/mmap.c 2009-02-20 13:40:26.0
+1100
+++ linux-2.6/arch
Randomise the lower bits of the stack address. More randomisation is good for
security but the scatter can also help with SMT threads that share an L1. A
quick test case shows this working:
int main()
{
int sp;
printf("%x\n", (unsigned long)&sp & 4095);
}
before:
80
80
80
80
80
a
The following set of patches adds randomisation of mmaps, heap and
position independent executables, and increases the randomisation applied to
the stack on 64bit binaries.
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mail
get_random_int() returns the same value within a 1 jiffy interval. This means
that the mmap and stack regions will almost always end up the same distance
apart, making a relative offset based attack possible.
To fix this, shift the randomness we use for the mmap region by 1 bit.
Signed-off-by: An
We currently place mmaps just below the stack on 32bit, but leave them
in the middle of the address space on 64bit:
0010-0012 r-xp 0010 00:00 0[vdso]
1000-1001 r-xp 08:06 179534 /tmp/sleep
1001-1002 rw-p 08:06 179534
At the moment we randomise the stack by 8MB on 32bit and 64bit tasks. Since we
have a lot more address space to play with on 64bit, lets do what x86 does and
increase that randomisation to 1GB:
before:
# for i in seq `1 10` ; do sleep 1 & cat /proc/${!}/maps | grep stack; done
febc000-fed1
On Wed, 18 Feb 2009 22:18:21 +0100
Giuliano Pochini wrote:
> /sys/devices/system/cpu/cpu*/online don't exist anymore.
I think I found the bug. Is this patch ok ?
Signed-off-by: Giuliano Pochini
--- linux-2.6.29-rc5/arch/powerpc/platforms/powermac/setup.c__orig
2009-02-14 00:31:30.0
On Sun, 2009-02-22 at 11:35 +0300, malc wrote:
> After writing valgrind tool that was simulating Cell XER.SO syscall
> (mis)behaviour (pre ab598b6680f1e74c267d1547ee352f3e1e530f89 that is)
> and banging my had against the wall for a while trying to figure out
> which of the failing syscalls was res
Hello,
This is getting frustrating and I am beginning to think someone messed this
board up and returned it. I would think it would boot up the default flash
image out of the box with very little trouble.
Board is a MPC8313e-RDB Rev A4. I set the dip switches per the instructions,
S4 all off
This adds the necessary bits and pieces to powerpc implementation of
ioremap to benefit from caller tracking in /proc/vmallocinfo, at least
for ioremap's done after mem init as the older ones aren't tracked.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/io.h
The for-loop body of identify_cpu() has gotten a little big, so move the
loop body logic into a separate function. No other changes.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/cputable.c | 122 +---
1 files changed, 64 insertions(+), 58 deletions
When identify_cpu() is called a second time with a logical PVR, it
only copies a subset of the cpu_spec fields so as to avoid overwriting
the performance monitor fields that were initialized based on the
real PVR.
However some of the other, non performance monitor related fields are
also not copie
On Sat, Feb 21, 2009 at 05:05:04PM +0100, Pierre Ossman wrote:
> On Fri, 20 Feb 2009 20:33:08 +0300
> Anton Vorontsov wrote:
>
> > From: Ben Dooks
> >
> > The Samsung SDHCI (and FSL eSDHC) controller block seems to fail
> > to generate an INT_DATA_END after the transfer has completed and
> > th
On Thu, 2009-02-12 at 17:54 -0600, Kumar Gala wrote:
> The e500mc supports the new msgsnd/doorbell mechanisms that were added in
> the Power ISA 2.05 architecture. We use the normal level doorbell for
> doing SMP IPIs at this point.
Any reason why you don't use the tag ? I'm not too familiar with
I have a AMCC Kilauea board and I want to use linux power-management
feature on it.
But it seems that there's no power-management codes for the powerpc 4xx
series.
I think the device-tree source for the Kilauea should be modified first.
Is there anyone who has tried it before?
Please help me.
> +/* for reprogramming DABR/DAC during restart of a checkpointed task */
> +extern bool debugreg_valid(unsigned long val);
> +extern void debugreg_update(struct task_struct *task, unsigned long val);
> +
Please keep the "index" here. We may want to add support for IABR, and
there is some WIP to
On Thu, 2009-02-19 at 18:07 +0100, Nick Piggin wrote:
> Setting G5's cpu frequency transition latency to CPUFREQ_ETERNAL stops
> ondemand governor from working. I measured the latency using sched_clock
> and haven't seen much higher than 11000ns, so I set this to 12000ns for
> my configuration. Pos
> -Original Message-
> From: linuxppc-dev-bounces+dusharaj=optiscan@ozlabs.org
> [mailto:linuxppc-dev-bounces+dusharaj=optiscan@ozlabs.org] On
> Behalf Of Dushara Jayasinghe
> Sent: Friday, 20 February 2009 6:18 PM
> To: 'Michael Bergandi'
> Cc: linuxppc-dev@ozlabs.org; Aggrwal Poon
In the handler for decrementer interrupt...there is a call to a C function...
Now if the call is removed...the decrementer interrupt works perfectly fine...
But if the C function is present, then the decrementer interrupt stops
coming after say 5-6 times...
Not able to find any reasoning for the sa
Thanks a lot...Its working now...
Regards,
Sumedh
On Thu, Feb 12, 2009 at 7:28 PM, Kumar Gala wrote:
>
> On Feb 12, 2009, at 3:59 AM, sumedh tirodkar wrote:
>
>> How will i confirm if PowerPC 7447A processor has or does not have a
>> dedicated hardware for page table search algorithm?
>> If it d
26 matches
Mail list logo
