On Tue, 10 Jul 2007, Jakub Jelinek wrote:
> Restore BAD_ADDR check strictness, use IS_ERR in the only place where
> the stricter BAD_ADDR can't work, as the value is a load bias rather
> than userland address.
> Signed-off-by: Jakub Jelinek <[EMAIL PROTECTED]>
Signed-off-by: Jiri Kosina <[EMAIL P
On Mon, Jul 09, 2007 at 11:58:07PM +0200, Jiri Kosina wrote:
> On Mon, 9 Jul 2007, Jiri Kosina wrote:
> > [ ... ]
> > > - if (!BAD_ADDR(elf_entry)) {
> > > + if (!IS_ERR((void *)elf_entry)) {
> > I agree that this is better solution. Andrew, this Jakub's patch should
On Mon, 9 Jul 2007, Jiri Kosina wrote:
> > Signed-off-by: Jakub Jelinek <[EMAIL PROTECTED]>
> [ ... ]
> > - if (!BAD_ADDR(elf_entry)) {
> > + if (!IS_ERR((void *)elf_entry)) {
> I agree that this is better solution. Andrew, this Jakub's patch should
> replace t
On Sat, 7 Jul 2007, Jakub Jelinek wrote:
> I believe BAD_ADDR macro was changes from ((unsigned long)(x) >=
> TASK_SIZE) (which is the right test for invalid user addresses, stronger
> check than >= PAGE_MASK) to >= PAGE_MASK only because of the one check
> of the return value of load_elf_inter
On Sat, Jul 07, 2007 at 02:13:01AM +0200, Jiri Kosina wrote:
> On Thu, 5 Jul 2007, Rik van Riel wrote:
>
> > So the original patch has:
> > #define BAD_ADDR(x) ((unsigned long)(x) >= TASK_SIZE)
> > For some reason(?) it got changed to the clearly buggy:
> > #define BAD_ADDR(x) ((unsigned long)(x)
On Thu, 5 Jul 2007, Rik van Riel wrote:
> So the original patch has:
> #define BAD_ADDR(x) ((unsigned long)(x) >= TASK_SIZE)
> For some reason(?) it got changed to the clearly buggy:
> #define BAD_ADDR(x) ((unsigned long)(x) >= PAGE_MASK)
> Jiri's patch undoes that second buggy define, which is ve
Chuck Ebbert wrote:
On 07/04/2007 01:35 PM, Jiri Kosina wrote:
On Wed, 4 Jul 2007, Jakub Jelinek wrote:
The above highlighted changes are the cause of random segfaults of PIE
binaries. See
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246623
Thanks a lot for pointing this out. Andrew
On 07/04/2007 01:35 PM, Jiri Kosina wrote:
> On Wed, 4 Jul 2007, Jakub Jelinek wrote:
>
>> The above highlighted changes are the cause of random segfaults of PIE
>> binaries. See
>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246623
>
> Thanks a lot for pointing this out. Andrew, cou
On Wed, 4 Jul 2007, Jakub Jelinek wrote:
> The above highlighted changes are the cause of random segfaults of PIE
> binaries. See
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246623
Thanks a lot for pointing this out. Andrew, could this be folded into
pie-randomization.patch please
On Wed, May 23, 2007 at 10:50:24AM +0200, Jiri Kosina wrote:
> From: Jan Kratochvil <[EMAIL PROTECTED]>
>
> This patch is using mmap()'s randomization functionality in such a way
> that it maps the main executable of (specially compiled/linked -pie/-fpie)
> ET_DYN binaries onto a random address
On Tue, 22 May 2007, Andrew Morton wrote:
> > This patch is using mmap()'s randomization functionality in such a way
> > that it maps the main executable of (specially compiled/linked
> > -pie/-fpie) ET_DYN binaries onto a random address (in cases in which
> > mmap() is allowed to perform a ran
On Thu, 17 May 2007 22:24:11 +0200 (CEST)
Jan Kratochvil <[EMAIL PROTECTED]> wrote:
> This patch is using mmap()'s randomization functionality in such a way
> that it maps the main executable of (specially compiled/linked -pie/-fpie)
> ET_DYN binaries onto a random address (in cases in which mma
On Thu, 17 May 2007, Jan Kratochvil wrote:
> Hi,
> sorry for insufficient description in my earlier post. I hope it is better
> this time.
>
> Jiri: Thanks for help, I applied your change on my previous patch.
>
> This patch is using mmap()'s randomization functionality in such a way that it
>
On Thu, 17 May 2007 22:24:11 +0200 (CEST)
Jan Kratochvil <[EMAIL PROTECTED]> wrote:
> This patch is using mmap()'s randomization functionality in such a way
> that it maps the main executable of (specially compiled/linked -pie/-fpie)
> ET_DYN binaries onto a random address (in cases in which mma
On Thu, 17 May 2007, Jan Kratochvil wrote:
> This patch is using mmap()'s randomization functionality in such a way
> that it maps the main executable of (specially compiled/linked
> -pie/-fpie) ET_DYN binaries onto a random address (in cases in which
> mmap() is allowed to perform a randomizat
Hi,
sorry for insufficient description in my earlier post. I hope it is better
this time.
Jiri: Thanks for help, I applied your change on my previous patch.
This patch is using mmap()'s randomization functionality in such a way
that it maps the main executable of (specially compiled/linked -pi
On Sat, 12 May 2007, Jiri Kosina wrote:
> However, I seem to get "soft" hang on boot with this patch,
> approximately at the time the init should be executed. The system is not
> completely stuck - interrupts are delivered, keyboard is working,
> alt-sysrq-t dumps proper output, but userspace d
On Fri, 11 May 2007, Andrew Morton wrote:
> I could reverse-engineer that info from the patch, I guess, but I'd
> prefer to go in the opposite direction: you tell us what the patch is
> trying to do, then we look at it and see if we agree that it is in fact
> doing that.
I've just quickly look
On 5/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
erm, I was being funny. If you randomize a binary it won't run any more.
cp /dev/random /bin/login. Oh well.
My point is, we're not being told what is being randomized here. Is it the
virtual starting address of the main executable mmap? O
On Fri, 11 May 2007 22:18:16 +0200 (CEST)
Jiri Kosina <[EMAIL PROTECTED]> wrote:
> On Fri, 11 May 2007, Andrew Morton wrote:
>
> > >I sent this patch 5 days ago, nobody replied. So I am giving it
> > > second attempt. Andrew, is it possible to test this in -mm branch?
> > > Original mail fo
On Fri, 11 May 2007, Andrew Morton wrote:
> >I sent this patch 5 days ago, nobody replied. So I am giving it
> > second attempt. Andrew, is it possible to test this in -mm branch?
> > Original mail follows:
> > this is something like reaction to this thread:
> > http://lkml.org/lkml/200
On Fri, 11 May 2007 14:33:46 +0200 (CEST)
Jan Kratochvil <[EMAIL PROTECTED]> wrote:
> Hello,
>I sent this patch 5 days ago, nobody replied. So I am giving it second
> attempt.
> Andrew, is it possible to test this in -mm branch?
> Original mail follows:
>
> Hi,
> this is something like r
Hello,
I sent this patch 5 days ago, nobody replied. So I am giving it second
attempt.
Andrew, is it possible to test this in -mm branch?
Original mail follows:
Hi,
this is something like reaction to this thread:
http://lkml.org/lkml/2007/1/6/124. I hope I was able to separate the PIE
ran
23 matches
Mail list logo
