* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > but what this discussion was about was the _dl_make_stack_executable()
> > function.
>
> the jury is still out on that one, i just don't have the time and beer
> to do the full research that a real exploit writer would do. in
> security, unless
* Julien TINNES <[EMAIL PROTECTED]> wrote:
> But if you consider code injection as in your previous post:
>
> >btw., do you consider PaX as a 100% sure solution against 'code
> >injection' attacks (meaning that the attacker wants to execute an
> >arbitrary piece of code, and assuming the attacke
i'm just curious, assuming that all those conditions are true, do you
consider PaX a 100% sure solution against 'code injection' attacks?
(assuming that the above PaX and access-control feature implementations
are correct.) Do you think the upstream kernel could/should integrate it
as a solution a
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > btw., do you consider PaX as a 100% sure solution against 'code
> > injection' attacks (meaning that the attacker wants to execute an
> > arbitrary piece of code, and assuming the attacked application has a
> > stack overflow)? I.e. does PaX avoi
> yes, i agree with you, __libc_dlopen_mode() is an easier target (but not
> _that_ easy of a target, see further down), and your code looks right
actually, line 25 is crap (talk about 'coding while intoxicated' ;-),
it should be 'if (dlerror())' of course. also, you should really try
to run the c
> btw., do you consider PaX as a 100% sure solution against 'code
> injection' attacks (meaning that the attacker wants to execute an
> arbitrary piece of code, and assuming the attacked application has a
> stack overflow)? I.e. does PaX avoid all such attacks in a guaranteed
> way?
your question
btw., do you consider PaX as a 100% sure solution against 'code
injection' attacks (meaning that the attacker wants to execute an
arbitrary piece of code, and assuming the attacked application has a
stack overflow)? I.e. does PaX avoid all such attacks in a guaranteed
way?
Ingo
-
To unsub
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > still wrong. What you get this way is a nice, complicated NOP.
>
> not only a nop but also a likely crash given that i didn't adjust
> the declaration of some_function appropriately ;-). let's cater
> for less complexity too with the following p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roman Zippel wrote:
> Hi,
>
> On Thu, 3 Feb 2005, Peter Busser wrote:
>
>
>>- What happens when you run existing commercial applications which have not
>>been compiled using GCC.
>
>
>>From http://pax.grsecurity.net/docs/pax.txt:
>
>The go
> still wrong. What you get this way is a nice, complicated NOP.
not only a nop but also a likely crash given that i didn't adjust
the declaration of some_function appropriately ;-). let's cater
for less complexity too with the following payload (of the 'many
other ways' kind):
[field1 and other
> From http://pax.grsecurity.net/docs/pax.txt:
>
>The goal of the PaX project is to research various defense mechanisms
>against the exploitation of software bugs that give an attacker arbitrary
>read/write access to the attacked task's address space.
>
> Could you please explain how
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > dl_make_stack_executable() will nicely return into user_input
> > > (at which time the stack has already become executable).
> >
> > wrong, _dl_make_stack_executable() will not return into user_input() in
> > your scenario, and your exploit wi
Hi,
On Thu, 3 Feb 2005, Peter Busser wrote:
> - What happens when you run existing commercial applications which have not
> been compiled using GCC.
>From http://pax.grsecurity.net/docs/pax.txt:
The goal of the PaX project is to research various defense mechanisms
against the exploitatio
> > dl_make_stack_executable() will nicely return into user_input
> > (at which time the stack has already become executable).
>
> wrong, _dl_make_stack_executable() will not return into user_input() in
> your scenario, and your exploit will be aborted. Check the glibc sources
> and the implementa
On Wednesday 02 February 2005 23:08, [EMAIL PROTECTED] wrote:
> > and how do you force a program to call that function and then to execute
> > your shellcode? In other words: i challenge you to show a working
> > (simulated) exploit on Fedora (on the latest fc4 devel version, etc.)
> > that does th
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > You can simulate the overflow itself so no need to find any real
> > application vulnerability, but show me _working code_ (or a convincing
> > description) that can call glibc's do_make_stack_executable() (or the
> > 'many ways of doing this'),
> and how do you force a program to call that function and then to execute
> your shellcode? In other words: i challenge you to show a working
> (simulated) exploit on Fedora (on the latest fc4 devel version, etc.)
> that does that.
i don't have any Fedora but i think i know roughly what you're
On Wed, Feb 02, 2005 at 10:18:27PM +1000, [EMAIL PROTECTED] wrote:
> your concerns would be valid if this was impossible to achieve by an
> exploit, sadly, you'd be wrong too, it's possible to force an exploited
> application to call something like dl_make_stack_executable() and then
> execute the
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> your concerns would be valid if this was impossible to achieve by an
> exploit, sadly, you'd be wrong too, it's possible to force an
> exploited application to call something like
> dl_make_stack_executable() and then execute the shellcode. [...]
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi!
> one thing that paxtest didn't get right in the 'kiddie' mode is that
> it still ran with an executable stack, that was not the intention but
> rather an oversight, it'll be fixed in the next release. still, this
> shouldn't leave you with a warm and fuzzy feeling about the security
> of intr
> Umm, so exactly how many applications use multithreading (or otherwise
> trigger the GLIBC mprotect call), and how many applications use nested
> functions (which is not ANSI C compliant, and as a result, very rare)?
i think you're missing the whole point of paxtest. it's not about what
glibc et
On Wednesday 02 February 2005 09:26, Theodore Ts'o wrote:
> On Tue, Feb 01, 2005 at 07:15:49PM -0500, Theodore Ts'o wrote:
> > Umm, so exactly how many applications use multithreading (or otherwise
> > trigger the GLIBC mprotect call),
>
> For the record, I've been informed that the glibc mprotect(
On Wed, 2005-02-02 at 10:35 +0100, Peter Busser wrote:
> Hi!
>
> > Umm, so exactly how many applications use multithreading (or otherwise
> > trigger the GLIBC mprotect call), and how many applications use nested
> > functions (which is not ANSI C compliant, and as a result, very rare)?
> >
> > Do
Hi!
> Umm, so exactly how many applications use multithreading (or otherwise
> trigger the GLIBC mprotect call), and how many applications use nested
> functions (which is not ANSI C compliant, and as a result, very rare)?
>
> Do the tests both ways, and document when the dummy() re-entrant
> func
On Tue, Feb 01, 2005 at 07:15:49PM -0500, Theodore Ts'o wrote:
> Umm, so exactly how many applications use multithreading (or otherwise
> trigger the GLIBC mprotect call),
For the record, I've been informed that the glibc mprotect() call
doesn't happen in any modern glibc's; there may have been o
On Tue, Feb 01, 2005 at 10:44:39AM +0100, Peter Busser wrote:
> Again, this is a *simulation* of the way real-life applications could
> interact
> with the underlying system. Again people complained that the results shown
> were not accurate. And that has been fixed.
>
> I am well aware of comp
El Tue, 1 Feb 2005 10:44:39 +0100 Peter Busser <[EMAIL PROTECTED]> escribió:
> > which is clearly there to sabotage any segmentation based approach (eg
> > execshield and openwall etc); it cannot have any other possible use or
> > meaning.
>
> Ah, so you are saying that I sabotaged PaXtest? Sorry
On Tuesday 01 February 2005 12:46, you wrote:
> * Peter Busser <[EMAIL PROTECTED]> wrote:
> > > ok the paxtest 0.9.5 I downloaded from a security site (not yours) had
> > > this gem in:
> > >
> > > + do_mprotect((unsigned long)argv & ~4095U, 4096,
> > > PROT_READ|PROT_WRITE|PROT_EXEC)
* Peter Busser <[EMAIL PROTECTED]> wrote:
> > ok the paxtest 0.9.5 I downloaded from a security site (not yours) had
> > this gem in:
> > + do_mprotect((unsigned long)argv & ~4095U, 4096,
> > PROT_READ|PROT_WRITE|PROT_EXEC);
> > which is clearly there to sabotage any segmentation
On Monday 31 January 2005 17:41, you wrote:
> On Mon, 2005-01-31 at 13:57 +0100, Peter Busser wrote:
> > Hi!
> >
> > > I'm not entirely happy yet (it shows a bug in mmap randomisation) but
> > > it's way better than what you get in your tests (this is the
> > > desabotaged
> > > 0.9.6 version fwiw)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
>>Why not compromise, if possible? 256M of randomization, but move the
>>split up to 3.5/0.5 gig, if possible. I seem to recall seeing an option
>>(though I think it was UML) to do 3.5/0.5 before; and I'm used to "a
>>littl
On Mon, 2005-01-31 at 13:57 +0100, Peter Busser wrote:
> Hi!
>
> > I'm not entirely happy yet (it shows a bug in mmap randomisation) but
> > it's way better than what you get in your tests (this is the
> > desabotaged
> > 0.9.6 version fwiw)
>
> As you may or may not know, I am the author of PaXt
Hi!
> I'm not entirely happy yet (it shows a bug in mmap randomisation) but
> it's way better than what you get in your tests (this is the
> desabotaged
> 0.9.6 version fwiw)
As you may or may not know, I am the author of PaXtest. Please tell me what a
``desabotaged'' version of PaXtest exactly
> Why not compromise, if possible? 256M of randomization, but move the
> split up to 3.5/0.5 gig, if possible. I seem to recall seeing an option
> (though I think it was UML) to do 3.5/0.5 before; and I'm used to "a
> little worse" meaning "microbenches say it's worse, but you won't notice
> it,"
On Sat, Jan 29, 2005 at 01:10:54PM -0500, John Richard Moser wrote:
> > Yeah, I guess your extensive compiler internals experience and knowledge
> > of gcc internals weights a lot more than the opinion of the gcc team..
> >
>
> I read "implementation" as "the way it's implemented," not as "the
>
On Sat, 29 Jan 2005, John Richard Moser wrote:
Did I miss the target? *Aims in the other direction then?*
Depends. If you aimed to kick your own arse, you did pretty well.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possib
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christoph Hellwig wrote:
> On Sat, Jan 29, 2005 at 12:49:05PM -0500, John Richard Moser wrote:
>
>>>The ideas in IBM's ProPolice changes are good and worth
>>>implementing, but the current implementation is bad.
>>>
>>
>>Lies. I've read the paper o
On Sat, Jan 29, 2005 at 12:49:05PM -0500, John Richard Moser wrote:
> > The ideas in IBM's ProPolice changes are good and worth
> > implementing, but the current implementation is bad.
> >
>
> Lies. I've read the paper on the current implementation, it's
> definitely good. It only operates on C
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jakub Jelinek wrote:
> On Sat, Jan 29, 2005 at 01:31:46AM -0500, John Richard Moser wrote:
>
>>Finally, although an NX stack is nice, you should probably take into
>>account IBM's stack smash protector, ProPolice. Any attack that can
>>evade SSP re
On Sat, Jan 29, 2005 at 01:31:46AM -0500, John Richard Moser wrote:
> Finally, although an NX stack is nice, you should probably take into
> account IBM's stack smash protector, ProPolice. Any attack that can
> evade SSP reliably can evade an NX stack; but ProPolice protects from
> other overflows
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arjan van de Ven wrote:
> On Sat, 2005-01-29 at 11:21 -0500, John Richard Moser wrote:
>
>>-BEGIN PGP SIGNED MESSAGE-
>>Hash: SHA1
>>
>>
>>
>>Arjan van de Ven wrote:
>>
I actually just tried to paxtest a fresh Fedora Core 3, unadultered,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arjan van de Ven wrote:
> On Sat, 2005-01-29 at 11:21 -0500, John Richard Moser wrote:
>
>>-BEGIN PGP SIGNED MESSAGE-
>
>
>>These are the only places mprotect() is mentioned; a visual scan
>>confirms no trickery:
>>
>>if( fork()
On Sat, 2005-01-29 at 11:21 -0500, John Richard Moser wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> Arjan van de Ven wrote:
> >>I actually just tried to paxtest a fresh Fedora Core 3, unadultered,
> >>that I installed, and it FAILED every test. After a while, spender
> >>remi
On Sat, 2005-01-29 at 11:21 -0500, John Richard Moser wrote:
> -BEGIN PGP SIGNED MESSAGE-
> These are the only places mprotect() is mentioned; a visual scan
> confirms no trickery:
>
> if( fork() == 0 ) {
> /* Perform a dirty (but not unrealistic) trick to circumve
> I actually just tried to paxtest a fresh Fedora Core 3, unadultered,
> that I installed, and it FAILED every test. After a while, spender
> reminded me about PT_GNU_STACK. It failed everything but the Executable
> Stack test after execstack -c *. The randomization tests gave
> 13(heap-etexec)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alright, I'll bite.
Someone told me to bring this up after reading all the complaints about
breakage, so again we get back to PaX. I'm more interested in "this
patch is bad" than "PaX is better" for this argument, but whatever.
Compatibility has be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rik van Riel wrote:
> On Thu, 27 Jan 2005, John Richard Moser wrote:
>
>> Arjan van de Ven wrote:
>
>
Is this one any worse?
>>>
>>> yes.
>>>
>>> oracle, db2 and similar like to mmap 2Gb or more *in one chunk*.
>>
>>
>> Special case?
>
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ingo Molnar wrote:
> * Paulo Marques <[EMAIL PROTECTED]> wrote:
>
>
>>I really shouldn't feed the trolls, but this must be the most silly
>>piece of code I saw on this mailing list in a very long time (and
>>there have been some good examples over
On Thu, 27 Jan 2005, John Richard Moser wrote:
Arjan van de Ven wrote:
Is this one any worse?
yes.
oracle, db2 and similar like to mmap 2Gb or more *in one chunk*.
Special case?
Absolutely, but ...
Can I get this put into perspective? How much more important is "Good"
randomization versus "not br
TECTED]>, linux-kernel@vger.kernel.org,
[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Patch 4/6 randomize the stack pointer
* Jirka Kosina <[EMAIL PROTECTED]> wrote:
Also, besides security implications of stack randomization, there is
one more aspect that should not be forgott
* Paulo Marques <[EMAIL PROTECTED]> wrote:
> I really shouldn't feed the trolls, but this must be the most silly
> piece of code I saw on this mailing list in a very long time (and
> there have been some good examples over time).
yeah.
> The stack randomization doesn't prevent some sort of atta
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paulo Marques wrote:
> John Richard Moser wrote:
>
>> In other words, no :)
>>
>> Here's self-exploiting code to discover its own return address offset
>> and exploit itself. It'll lend some insight into how this stuff works.
>
>
> I really shoul
John Richard Moser wrote:
In other words, no :)
Here's self-exploiting code to discover its own return address offset
and exploit itself. It'll lend some insight into how this stuff works.
I really shouldn't feed the trolls, but this must be the most silly
piece of code I saw on this mailing list
Horst von Brand wrote:
Julien TINNES <[EMAIL PROTECTED]> said:
Not very important but ((get_random_int() % 4096) << 4) could be
optimized into get_random_int() & 0xFFF0.
Check first if the compiler doesn't do it by itself.
The compiler cannot guess that get_random_int() gives a random result.
%4
> I thought that this was the original purpose of the "stack randomization"
> which is shipped for example by RedHat kernels, as the randomization is
> quite small and easy to bruteforce, so it can't serve too much as a buffer
> overflow protection.
correct; that was for the p4 hyperthreading
* Jirka Kosina <[EMAIL PROTECTED]> wrote:
> Also, besides security implications of stack randomization, there is
> one more aspect that should not be forgotten - stack randomization
> (even for quite small range) could be useful to distribute a pressure
> on cache (which may not be fully associat
Julien TINNES <[EMAIL PROTECTED]> said:
> Not very important but ((get_random_int() % 4096) << 4) could be
> optimized into get_random_int() & 0xFFF0.
Check first if the compiler doesn't do it by itself.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Infor
Roland Dreier wrote:
Julien> Not very important but ((get_random_int() % 4096) << 4)
Julien> could be optimized into get_random_int() & 0xFFF0.
HPA> .. and gcc knows that.
HPA>8: 25 ff 0f 00 00 and$0xfff,%eax
HPA>d: 83 c4 0cadd$0xc,%e
Julien> Not very important but ((get_random_int() % 4096) << 4)
Julien> could be optimized into get_random_int() & 0xFFF0.
HPA> .. and gcc knows that.
HPA>8: 25 ff 0f 00 00 and$0xfff,%eax
HPA>d: 83 c4 0cadd$0xc,%esp
HPA> 10:
Followup to: <[EMAIL PROTECTED]>
By author:Julien TINNES <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Not very important but ((get_random_int() % 4096) << 4) could be
> optimized into get_random_int() & 0xFFF0. Because 4096 is a power of 2
> you won't loose any entropy by doing &
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arjan van de Ven wrote:
>>I feel the need to point something out here.
>>
>>[TEXT][BRK][MMAP---][STACK]
>>
>>Here's a normal layout.
>>
>>[TEXT][BRK][MMAP---][STACK][MMAP--]
>>
>>Is this one any worse?
>
>
> yes.
>
> oracle, db2 an
On Thu, 27 Jan 2005, John Richard Moser wrote:
> Your patch 5/6 for mmap rand is also small. 1M is trivial, though I'd
> imagine mmap() rand would pose a bit more confusion in some cases at
> least, even for small ranges.
> Still, this is a joke, like OpenBSD's stackgap.
Also, besides security i
> I feel the need to point something out here.
>
> [TEXT][BRK][MMAP---][STACK]
>
> Here's a normal layout.
>
> [TEXT][BRK][MMAP---][STACK][MMAP--]
>
> Is this one any worse?
yes.
oracle, db2 and similar like to mmap 2Gb or more *in one chunk*.
moving the stack in the middle m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus Torvalds wrote:
>
[...]
>
> Your suggestion of 256MB of randomization for the stack SIMPLY IS NOT
> ACCEPTABLE for a lot of uses. People on 32-bit archtiectures have issues
> with usable virtual memory areas etc.
>
I feel the need to po
>
> Here's self-exploiting code to discover its own return address offset
> and exploit itself. It'll lend some insight into how this stuff works.
>
> Just a toy.
>
While I understand the point here, doesn't it become a moot point if:
a) the stack is reinitialized randomly on each execution
and
On Thu, 27 Jan 2005, Arjan van de Ven wrote:
>
> and then there are architectures with an upward growing stack
> and maybe the alignment will even vary per cpu type (runtime) for some
> architectures? Maybe arch maintainers can jump in quickly to say if a
> scheme with a per arch shift facto
On Thu, 2005-01-27 at 20:42 +, Christoph Hellwig wrote:
> On Thu, Jan 27, 2005 at 03:40:48PM -0500, Rik van Riel wrote:
> > On Thu, 27 Jan 2005, Christoph Hellwig wrote:
> >
> > >>+unsigned long arch_align_stack(unsigned long sp)
> > >>+{
> > >>+ if (randomize_va_space)
> > >>+ sp -= (
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
So 0x02020202 is a no-op?
(somebody finally gets why the randomization range must be > the size of
the stack?)
linux-os wrote:
[...]
>> pointing back into that buffer needs the address of that buffer. That
>> buffer is on the stack, which is now ra
On Thu, 27 Jan 2005, Christoph Hellwig wrote:
+unsigned long arch_align_stack(unsigned long sp)
+{
+ if (randomize_va_space)
+ sp -= ((get_random_int() % 4096) << 4);
+ return sp & ~0xf;
+}
this looks like it'd work nicely on all architectures.
I guess it should work for a
On Thu, Jan 27, 2005 at 03:40:48PM -0500, Rik van Riel wrote:
> On Thu, 27 Jan 2005, Christoph Hellwig wrote:
>
> >>+unsigned long arch_align_stack(unsigned long sp)
> >>+{
> >>+ if (randomize_va_space)
> >>+ sp -= ((get_random_int() % 4096) << 4);
> >>+ return sp & ~0xf;
> >>+}
> >
On Thu, 27 Jan 2005, Arjan van de Ven wrote:
On Thu, 2005-01-27 at 14:19 -0500, linux-os wrote:
Gentlemen,
Isn't the return address on the stack an offset in the
code (.text) segment?
How would a random stack-pointer value help? I think you would
need to start a program at a random offset, not the
On Thu, 2005-01-27 at 20:32 +, Christoph Hellwig wrote:
> > The patch below replaces the existing 8Kb randomisation of the userspace
> > stack pointer (which is currently only done for Hyperthreaded P-IVs) with a
> > more general randomisation over a 64Kb range. 64Kb is not a lot, but it's a
>
> The patch below replaces the existing 8Kb randomisation of the userspace
> stack pointer (which is currently only done for Hyperthreaded P-IVs) with a
> more general randomisation over a 64Kb range. 64Kb is not a lot, but it's a
> start and once the dust settles we can increase this value to a mo
On Thu, Jan 27, 2005 at 08:23:35PM +, Christoph Hellwig wrote:
> > + p = arch_align_stack((unsigned long)p);
>
> looking at the code p already is unsigned long, so the cast is not needed.
yeah
how about this one instead ?
The patch below replaces the existing 8Kb randomisation o
> + p = arch_align_stack((unsigned long)p);
looking at the code p already is unsigned long, so the cast is not needed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
In other words, no :)
Here's self-exploiting code to discover its own return address offset
and exploit itself. It'll lend some insight into how this stuff works.
Just a toy.
Arjan van de Ven wrote:
> On Thu, 2005-01-27 at 14:19 -0500, linux-os wrote:
>
>>Gentlemen,
>>
>>Isn't the return addre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus Torvalds wrote:
>
> On Thu, 27 Jan 2005, John Richard Moser wrote:
>
>>>Your suggestion of 256MB of randomization for the stack SIMPLY IS NOT
>>>ACCEPTABLE for a lot of uses. People on 32-bit archtiectures have issues
>>>with usable virtual
On Thu, 2005-01-27 at 11:59 -0800, Linus Torvalds wrote:
>
> Btw, since you're clearly at the keyboard now: I do agree with Christoph
> that it would be a lot cleaner to just say that all architectures have to
> have a arch_align_stack() define, instead of having a
> __HAVE_ARCH_ALIGN_STACK define
On Thu, 2005-01-27 at 14:19 -0500, linux-os wrote:
> Gentlemen,
>
> Isn't the return address on the stack an offset in the
> code (.text) segment?
>
> How would a random stack-pointer value help? I think you would
> need to start a program at a random offset, not the stack!
> No stack-smasher tha
Btw, since you're clearly at the keyboard now: I do agree with Christoph
that it would be a lot cleaner to just say that all architectures have to
have a arch_align_stack() define, instead of having a
__HAVE_ARCH_ALIGN_STACK define.
After all, a trivial implementation would apparently just be
Gentlemen,
Isn't the return address on the stack an offset in the
code (.text) segment?
How would a random stack-pointer value help? I think you would
need to start a program at a random offset, not the stack!
No stack-smasher that worked would care about the value of
the stack-pointer.
While expl
> The fact is, different people have different needs. YOU only need to care
> about yourself. That's not true for a vendor. A single case that doesn't
> work ends up either (a) being ignored or (b) costing them money. See the
> problem? They can't win. Except by taking small steps, where the brea
Not very important but ((get_random_int() % 4096) << 4) could be
optimized into get_random_int() & 0xFFF0. Because 4096 is a power of 2
you won't loose any entropy by doing & 0xFFF instead of %4096
Regards,
--
Julien TINNES - & france telecom - R&D Division/MAPS/NSS
Research Engineer - Internet
On Thu, 27 Jan 2005, John Richard Moser wrote:
>
> > Your suggestion of 256MB of randomization for the stack SIMPLY IS NOT
> > ACCEPTABLE for a lot of uses. People on 32-bit archtiectures have issues
> > with usable virtual memory areas etc.
>
> It never bothered me on my Barton core or Thoro
Gentlemen,
Isn't the return address on the stack an offset in the
code (.text) segment?
How would a random stack-pointer value help? I think you would
need to start a program at a random offset, not the stack!
No stack-smasher that worked would care about the value of
the stack-pointer.
Cheers,
Dic
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus Torvalds wrote:
>
> On Thu, 27 Jan 2005, Linus Torvalds wrote:
>
>>Real engineering is about doing a good job balancing different issues.
>
>
[...]
> test. Maybe such a vendor understands that you have to ease into things,
> and you can'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus Torvalds wrote:
>
> On Thu, 27 Jan 2005, John Richard Moser wrote:
>
>>What the hell?
>
>
> John. Stop frothing at the mouth already!
>
I'm coarse, I'm not angry.
> Your suggestion of 256MB of randomization for the stack SIMPLY IS NOT
>
On 27 Jan 2005, at 19:04, John Richard Moser wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
What the hell?
So instead of bringing something in that works, you bring something in
that does significantly less, and gives no savings on overhead or patch
complexity why? So you can later come out
On Thu, 27 Jan 2005, Linus Torvalds wrote:
>
> Real engineering is about doing a good job balancing different issues.
Btw, this is true of real security too.
Being too strict "because it's the secure way" just means that people will
disable you altogether, or start doing things that they kno
On Thu, 27 Jan 2005, John Richard Moser wrote:
>
> What the hell?
John. Stop frothing at the mouth already!
Your suggestion of 256MB of randomization for the stack SIMPLY IS NOT
ACCEPTABLE for a lot of uses. People on 32-bit archtiectures have issues
with usable virtual memory areas etc.
>
John,
coult you please piss off and troll elsewhere?
thanks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, 2005-01-27 at 13:04 -0500, John Richard Moser wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> What the hell?
>
> So instead of bringing something in that works, you bring something in
> that does significantly less, and gives no savings on overhead or patch
> complexity why?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
What the hell?
So instead of bringing something in that works, you bring something in
that does significantly less, and gives no savings on overhead or patch
complexity why? So you can later come out and say "We're so great now
we've increased the ra
On Thu, 2005-01-27 at 12:38 -0500, John Richard Moser wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> Arjan van de Ven wrote:
> >
> > The patch below replaces the existing 8Kb randomisation of the userspace
> > stack pointer (which is currently only done for Hyperthreaded P-IVs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arjan van de Ven wrote:
>
> The patch below replaces the existing 8Kb randomisation of the userspace
> stack pointer (which is currently only done for Hyperthreaded P-IVs) with a
> more general randomisation over a 64Kb range.
>
64k of stack rand
> -#ifdef CONFIG_X86_HT
> +#ifdef __HAVE_ARCH_ALIGN_STACK
> /*
>* In some cases (e.g. Hyper-Threading), we want to avoid L1
>* evictions by the processes running on the same package. One
>* thing we can do is to shuffle the initial stack
The patch below replaces the existing 8Kb randomisation of the userspace
stack pointer (which is currently only done for Hyperthreaded P-IVs) with a
more general randomisation over a 64Kb range.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
diff -purN linux-step-2/arch/i386/kernel/proces
98 matches
Mail list logo
