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
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
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
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
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
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_interp.
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 the
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 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
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 very
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.
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, could this
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.
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
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 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 (in
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 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
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
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
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 mmap()
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, 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
maps
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
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 mmap()
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
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
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
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
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
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
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
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?
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
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:
> >
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
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
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
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 reaction
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:
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 follows:
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? Of
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 looked
46 matches
Mail list logo
