Make CPython segfault in 5 lines of code • Hacker News Board

Re: Make CPython segfault in 5 lines of code

#61

Post by h2odragon » Thu, Dec 19, 2019, 2:14 PM UTC

loeg wrote: post #44

Thorrez wrote: post #10

Earlier quoted context omitted.

Here's a Python 2 segfault I ran into recently. import sys, threading, time t = threading.Thread(target=sys.stdin.read, args=(1,)) t.start() time.sleep(1) sys.stdin.close() Run it then after a few seconds press enter. It doesn't segfault in Python 3, but it still doesn't behave how I'd like, because I would like the close() to unblock the read(), but it doesn't unblock the read(), the read() still hangs until it gets…

The whole threading library in Python is a mess. Python was designed around single threaded programs with shared-nothing state and the cracks show as you move beyond that. The whole idea of replacing the GIL with... multiple same-process distinct-state Python interpreters with cheap-ish message passing sort of highlights how ugly it gets.

Back around python 1.5, there was almost a fork of python where every object had locks, there were memory arenas, and multiprocessing was almost thoughtlessly easy. That and stackless would've been great.

Re: Make CPython segfault in 5 lines of code

#62

Post by PixyMisa » Thu, Dec 19, 2019, 2:29 PM UTC

h2odragon wrote: post #61

loeg wrote: post #44

Earlier quoted context omitted.

The whole threading library in Python is a mess. Python was designed around single threaded programs with shared-nothing state and the cracks show as you move beyond that. The whole idea of replacing the GIL with... multiple same-process distinct-state Python interpreters with cheap-ish message passing sort of highlights how ugly it gets.

Back around python 1.5, there was almost a fork of python where every object had locks, there were memory arenas, and multiprocessing was almost thoughtlessly easy. That and stackless would've been great.

It was also terribly slow.

IronPython did that too, on .Net. It ran around one quarter the speed of CPython.

Re: Make CPython segfault in 5 lines of code

#63

Post by snek » Thu, Dec 19, 2019, 3:24 PM UTC

shakna wrote: post #46

tus88 wrote: post #17

Earlier quoted context omitted.

> Segfaults in scripting languages are remarkably common What about Javascript running on V8?

Yes, even there. [0] [0] https://github.com/nodejs/node/pulls?utf8=%E2%9C%93&q=is%3Ap...

node dev here - none of the prs here deal with segfaults from js code, because that doesn't really happen (at least, I've never seen it happen). You might have some more success searching V8's bug tracker.

Re: Make CPython segfault in 5 lines of code

#64

Post by shakna » Thu, Dec 19, 2019, 3:30 PM UTC

snek wrote: post #63

shakna wrote: post #46

Earlier quoted context omitted.

Yes, even there. [0] [0] https://github.com/nodejs/node/pulls?utf8=%E2%9C%93&q=is%3Ap...

node dev here - none of the prs here deal with segfaults from js code, because that doesn't really happen (at least, I've never seen it happen). You might have some more success searching V8's bug tracker.

This [0] one had a segfault in a JS test file.

[0] https://github.com/nodejs/node/pull/22273#issuecomment-41588...

Re: Make CPython segfault in 5 lines of code

#65

Post by westurner » Thu, Dec 19, 2019, 4:01 PM UTC

FWIW, this segfaults CPython in 2 lines:

  import ctypes
  ctypes.cast(1, ctypes.py_object)

Interestingly, this works:

  import ctypes, gc
  x = 22
  _id = id(x)
  del x
  gc.collect()
  y = ctypes.cast(_id, ctypes.py_object).value
  assert y == 22

Re: Make CPython segfault in 5 lines of code

#66

Post by chubot » Thu, Dec 19, 2019, 6:29 PM UTC

WoodTree wrote: post #42

chubot wrote: post #41

Earlier quoted context omitted.

Thanks, removed. I’m sort of surprised by that since my memory is that infinity isn’t a real number, rational, etc. That is, does infinity in Haskell obey some algebraic laws?

Infinity is a valid floating point number in the ISO standard. However integer division by 0 isn’t. div 1 0 will fail.

Yeah it's an interesting case. It appears that Inf is in floating point to AVOID a trapped error.

This answer has an interesting way of looking at it. If you go on the theory that floating points are supposed to represent reals, then in floating point, you can't tell if a value is actually zero or just indistinguishably close to zero.

In the case of "indistinguishably close to zero", you're getting the wrong answer, and the program doesn't halt. It keeps on chugging doing bad math. So that's an untrapped error, and it's UNSAFE by Cardelli's definition.

https://cs.stackexchange.com/questions/82811/why-do-floating...

The key point is that "safe" sometimes means "crashes" and sometimes means "doesn't crash". It's an auto-antonym in that sense.

A broader definition is "errors are flagged as early as possible", including with seg faults / hardware exceptions.

Re: Make CPython segfault in 5 lines of code

#67

Post by lpghatguy » Thu, Dec 19, 2019, 7:04 PM UTC

tom_mellior wrote: post #51

lpghatguy wrote: post #7

Segfaults in scripting languages are remarkably common, especially if arbitrary bytecode can be loaded into the VM. One I ran into in the wild recently is that in older versions of Lua, exceptions in GC finalizers (the `__gc` metamethod) can trigger a segfault. In those same versions of Lua, the bytecode format is notoriously dangerous to load. I wonder whether this will be a large component of newer scripting langua…

> In those same versions of Lua, the bytecode format is notoriously dangerous to load. Could you expand on this? Are the dangers such that they could be avoided with a bytecode verifier somewhat like Java's? Things like checking that the stack can never underflow, and that at the merge points of branches the stack always has the same depth.

Here are two slide decks talking (roughly) about real-world attacks against Lua 5.1 and 5.2's bytecode:

5.1: https://www.lua.org/wshop11/Cawley.pdf

5.2: https://apocrypha.numin.it/talks/lua_bytecode_exploitation.p...

Lua used to have a built-in bytecode verifier as I understand it, but it never reached the point to where it was enough to safeguard the VM.

Re: Make CPython segfault in 5 lines of code

#68

Post by rini17 » Thu, Dec 19, 2019, 8:34 PM UTC

wizzwizz4 wrote: post #59

Thaxll wrote: post #11

Earlier quoted context omitted.

Segfault inside the runtime, What does it means exactly? A segfault is by definition at the OS level. WebAssembly koolaid is strong on HN, let's wait the first exploits that escapes the runtime to assess the "fully-safe" architecture.

I think they're trying to say that an out of bounds memory access within the emulated WebAssembly machine can be caught by the WebAssembly runtime. (I don't know whether this is true; I hardly know anything about WebAssembly.) The way they said it, though, makes it sound like WebAssembly is implemented with full process sandboxing or something, which is patently false. It works that way in neither Chrome nor Firefox,…

WebAssembly follows the unfortunate C paradigm that no checks are done at runtime, only these that programmer requests explicitly (and only if no undefined behavior is involved), to improve speed.

The WASM sandbox can call only set of specified host functions, but I expect so much functionality snowballing inside sandboxes that we'll have to allow everything including unsafe ones, anyway.

Re: Make CPython segfault in 5 lines of code

#69

Post by snek » Thu, Dec 19, 2019, 9:03 PM UTC

shakna wrote: post #64

snek wrote: post #63

Earlier quoted context omitted.

node dev here - none of the prs here deal with segfaults from js code, because that doesn't really happen (at least, I've never seen it happen). You might have some more success searching V8's bug tracker.

This [0] one had a segfault in a JS test file. [0] https://github.com/nodejs/node/pull/22273#issuecomment-41588...

it was not caused by a failure of the js vm though, it was caused (from what i can tell) by a failure in c++ tracing code.

Re: Make CPython segfault in 5 lines of code

#70

Post by Dylan16807 » Thu, Dec 19, 2019, 10:12 PM UTC

rini17 wrote: post #68

wizzwizz4 wrote: post #59

Earlier quoted context omitted.

I think they're trying to say that an out of bounds memory access within the emulated WebAssembly machine can be caught by the WebAssembly runtime. (I don't know whether this is true; I hardly know anything about WebAssembly.) The way they said it, though, makes it sound like WebAssembly is implemented with full process sandboxing or something, which is patently false. It works that way in neither Chrome nor Firefox,…

WebAssembly follows the unfortunate C paradigm that no checks are done at runtime, only these that programmer requests explicitly (and only if no undefined behavior is involved), to improve speed. The WASM sandbox can call only set of specified host functions, but I expect so much functionality snowballing inside sandboxes that we'll have to allow everything including unsafe ones, anyway.

WebAssembly uses 32 bit indexes to access memory. The default way of implementing memory safety for it is to put a few gigabytes of dead address space before and after the memory a WASM program uses. This makes it impossible for the memory access instructions to escape, despite having no runtime checks.

So it can segfault all the way up to the machine level. But more importantly, it's safe for it to 'segfault' out of its allocated memory, because it can't reach any other memory with 32 bit numbers.