lkml.org 
[lkml]   [2011]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v5 8/9] x86-64: Emulate legacy vsyscalls
    On 6 Jun 2011 at 23:01, Linus Torvalds wrote:

    > On Mon, Jun 6, 2011 at 8:56 PM, <pageexec@freemail.hu> wrote:
    > >
    > > it's *irrelevant*. this change you propose would go into future kernels,
    > > it would not affect existing ones, obviously. therefore anyone possibly
    > > affected would have to update his kernel first at which point they have
    > > no excuse to not update their libc of whatever flavour as well.
    >
    > Christ.
    >
    > Heard about that thing called "backwards compatibility"?
    >
    > We *require* that those "future kernels" run the old unmodified binaries.

    both Andy's and my approach work with 'old unmodified binaries'. by virtue
    of those 'new modified binaries' not existing (hint: glibc's intentionally
    not changed for static binaries).

    all the compatibility talk is about performance impact, not black&white 'runs
    or fails'. but more on this 'requirement' of yours below. you just so shot
    yourself in the foot, it's not even funny ;).

    > Yeah, I know you don't have that requirement,

    you don't know jack then. i do allow old binaries to work for every PaX feature
    i've ever introduced, even at the non-considerable expense of having to make
    special cases for them.

    > but anything that actually wants to be considered *relevant* and
    > actually merged into a mainline kernel does have that requirement. So
    > your argument is utter crap, ignorant, and stupid.

    watch your words Linus, you're about to eat them ;).

    > No, we don't update any libraries for a kernel upgrade. Ever. End of story.

    then you *must* revert the utterly *wrong* heap/stack gap 'fix' of yours that
    you cooked up without any public discussion a year ago and have been 'fixing'
    it for various userland breakage ever since.

    you know what you did? you *broke* a userland API, namely /proc/pid/maps. you
    broke it so badly that it breaks every app that wanted to do its own stack
    expansion tracking.

    one particular case i'm aware of is the Sun JVM that tries to map a guard page
    below what it thinks is the stack. except thanks to your very broken idea of
    lying about it in maps, it will actually map *over* the real last page of the
    stack, effectively *moving* its lower bound up, without having intended to do
    so (and without having done so under earlier kernels).

    in other words, a simple userland mmap request can now change *another* map.
    *that* is a clear violation of your own principles (not that i think you have
    any, your argument style is to throw out random shit whenever you think it
    serves your purpose, and not able to defend it when faced with real argumemts).

    but that's still not the end of the story. whenever userland code hits that
    carelessly hidden guard page, it'll cause a page fault that the JVM's segfault
    handler can't identify as its own since the fault didn't occur in what it
    thinks is the stack guard page. a really brilliant solution Linus, you must
    be very proud of it. what a pity that now you get to revert the whole shit
    and implement it properly (i don't need to tell you where you can find such
    a working solution, do i).

    cheers,

    PaX Team



    \
     
     \ /
      Last update: 2011-06-06 16:59    [W:0.028 / U:30.884 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site