linux-kernel - Re: [RFC] mlock/stack guard interaction fixup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100822190404.GA12445@suse.de>
Date:	Sun, 22 Aug 2010 12:04:04 -0700
From:	Greg KH <gregkh@...e.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ian Campbell <ijc@...lion.org.uk>, linux-kernel@...r.kernel.org,
	stable@...nel.org, stable-review@...nel.org,
	akpm@...ux-foundation.org, alan@...rguk.ukuu.org.uk,
	Peter Zijlstra <peterz@...radead.org>,
	Jeremy Fitzhardinge <jeremy@...p.org>
Subject: Re: [RFC] mlock/stack guard interaction fixup

On Sun, Aug 22, 2010 at 11:21:34AM -0700, Linus Torvalds wrote:
> On Sun, Aug 22, 2010 at 10:25 AM, Greg KH <gregkh@...e.de> wrote:
> >>
> >> Greg, we are talking about:
> >> 0e8e50e20c837eeec8323bba7dcd25fe5479194c mm: make stack guard page logic use vm_prev pointer
> >> 7798330ac8114c731cfab83e634c6ecedaa233d7 mm: make the mlock() stack guard page checks stricter
> >> 297c5eee372478fc32fec5fe8eed711eedb13f3d mm: make the vma list be doubly linked
> >
> > I must be missing something, but aren't these patches just "cleanups"
> > and changing the logic here to be nicer? ?Or do they fix real problems
> > with the previous stack guard stuff?
> >
> > Is it the second one you really need here?
> 
> They're all "required" (#2 needs #1, and #3 is a fix for something
> that can happen in the same circumstances that #2 makes any
> difference).

Ok, thanks.

> Although you do need to have some really odd things going on for any
> of them to make any difference. Notably, you need to do mlock or
> mprotect on the stack segment, which no sane program does.
> 
> That said, the change from
> 
>     start += PAGE_SIZE;
> 
> to
> 
>     addr += PAGE_SIZE;
> 
> in __mlock_vma_pages_range() (in #3) is a bugfix even for the normal
> mlockall() case. Not that anybody will realistically care about that
> either: the failure case just doesn't really realistically ever matter
> (it expands the stack which the code tries to avoid, and possibly
> forgets to mlock the bottom of the stack).
> 
> So I wouldn't call them high priority. Ian is doing something _really_
> odd. Doing hypercalls from user space on stuff that is on the stack,
> rather than just copying it to some stable area is dodgy. And I
> guarantee that doing the crazy mlock dance is slower than the copy, so
> it's complex, fragile, _and_ slow.

Heh, ok, I'll not worry about this for the .27 kernel then, that makes
it a lot easier for me :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/