On Wed, Mar 7, 2018 at 6:01 AM, Waldek Kozaczuk <jwkozac...@gmail.com> wrote:
> Nadav, > gic with malloc()? > >> >> Hmm, I just now realized you were using mprotect() to guard one page on >> the end of the stack (i.e., its beginning) and not the entire thing :-) >> Makes more sense now... >> I can't say I understand why mmap() should not work here. Sounds like it >> should have... We're already using mmap() for stacks, successfully. >> To implement a canary with malloc() what you can do is to put a fixed >> value, say 0xdeadbeef, in the beginning of the stack buffer, and every time >> you exit from a system call, you check that it still has this value. >> This doesn't catch stack overflows immediately, but at least it will not >> allow some other thread who's data we just ruined to run. It's not >> foolproof though - it's possible that the data we overflowed is actually >> OSv's own data and ruining it messed with the function of the system call >> itself. >> > > I think we can implement canary logic later. > Right. Maybe a canary would have been useful for you for debugging which stack sizes are enough, but if you already got things working, we can postpone this. > So meanwhile I will stick to regular malloc(). Also isn't my problems with > mmap()/mprotectd() related to this issue - https://github.com/cloudius- > systems/osv/issues/143 ? > I don't see how it's related - issue 143 is about using mmap() *without* the populate option, so that the page is only populated when first used (lazy allocation). But you're giving the populate option, right? -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
