How much do we care about undefined behavior triggered by invalid bytecode?

How much do we care about undefined behavior triggered by invalid bytecode?

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 235 bytes --]

It's pretty easy to find examples of (printed representations of) invalid
bytecode that trigger C-level assertions or undefined behavior ("crashes").
Should these be reported as bugs, or do we assume that any bytecode object
is valid?

[-- Attachment #2: Type: text/html, Size: 271 bytes --]

Re: How much do we care about undefined behavior triggered by invalid bytecode?

[Noam Postavsky]

On 22 May 2018 at 09:31, Philipp Stephani <p.stephani2@gmail.com> wrote:
> It's pretty easy to find examples of (printed representations of) invalid
> bytecode that trigger C-level assertions or undefined behavior ("crashes").
> Should these be reported as bugs, or do we assume that any bytecode object
> is valid?

The latter, according to the manual (elisp) Byte-Code Objects:

   You should not try to come up with the elements for a byte-code
function yourself, because if they are inconsistent, Emacs may crash
when you call the function.  Always leave it to the byte compiler to
create these objects; it makes the elements consistent (we hope).

Re: How much do we care about undefined behavior triggered by invalid bytecode?

[Andreas Schwab]

On Mai 22 2018, Noam Postavsky <npostavs@gmail.com> wrote:

> On 22 May 2018 at 09:31, Philipp Stephani <p.stephani2@gmail.com> wrote:
>> It's pretty easy to find examples of (printed representations of) invalid
>> bytecode that trigger C-level assertions or undefined behavior ("crashes").
>> Should these be reported as bugs, or do we assume that any bytecode object
>> is valid?
>
> The latter, according to the manual (elisp) Byte-Code Objects:
>
>    You should not try to come up with the elements for a byte-code
> function yourself, because if they are inconsistent, Emacs may crash
> when you call the function.  Always leave it to the byte compiler to
> create these objects; it makes the elements consistent (we hope).

Nevertheless, IMHO the bytecode interpreter should be made robust where
possible.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: How much do we care about undefined behavior triggered by invalid bytecode?

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 973 bytes --]

Noam Postavsky <npostavs@gmail.com> schrieb am Di., 22. Mai 2018 um
15:42 Uhr:

> On 22 May 2018 at 09:31, Philipp Stephani <p.stephani2@gmail.com> wrote:
> > It's pretty easy to find examples of (printed representations of) invalid
> > bytecode that trigger C-level assertions or undefined behavior
> ("crashes").
> > Should these be reported as bugs, or do we assume that any bytecode
> object
> > is valid?
>
> The latter, according to the manual (elisp) Byte-Code Objects:
>
>    You should not try to come up with the elements for a byte-code
> function yourself, because if they are inconsistent, Emacs may crash
> when you call the function.  Always leave it to the byte compiler to
> create these objects; it makes the elements consistent (we hope).
>

That refers only to calling bytecode objects, not to e.g. reading their
printed representation. Would it also apply to reading or other forms of
handling bytecode objects? If so, the documentation should say so.

[-- Attachment #2: Type: text/html, Size: 1370 bytes --]

Re: How much do we care about undefined behavior triggered by invalid bytecode?

[Noam Postavsky]

On 22 May 2018 at 10:04, Philipp Stephani <p.stephani2@gmail.com> wrote:

> That refers only to calling bytecode objects, not to e.g. reading their
> printed representation. Would it also apply to reading or other forms of
> handling bytecode objects? If so, the documentation should say so.

Oh, you meant just reading the object causes a crash? That sounds like a bug.

Re: How much do we care about undefined behavior triggered by invalid bytecode?

[Paul Eggert]

Noam Postavsky wrote:
> Oh, you meant just reading the object causes a crash?

I doubt he meant that. Surely he meant that if you read and then execute a 
bytecode object, you can easily crash Emacs.

We could fix this problem by verifying that a series of bytecodes cannot make 
Emacs crash, before allowing the bytecodes to be executed. But wouldn't that be 
a reasonably large project?

Re: How much do we care about undefined behavior triggered by invalid bytecode?

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 567 bytes --]

Paul Eggert <eggert@cs.ucla.edu> schrieb am Di., 22. Mai 2018 um 16:51 Uhr:

> Noam Postavsky wrote:
> > Oh, you meant just reading the object causes a crash?
>
> I doubt he meant that. Surely he meant that if you read and then execute a
> bytecode object, you can easily crash Emacs.
>
>
No, I did mean "read." For example, the following triggers an assertion:


emacs -Q -batch -eval '(let ((load-force-doc-strings t)) (read "#[0
\"\"]"))'


./lisp.h:1723: Emacs fatal error: assertion failed: 0 <= idx && idx < ASIZE
(array)
Fatal error 6: Abort trapAbort trap: 6

[-- Attachment #2: Type: text/html, Size: 1167 bytes --]

Re: How much do we care about undefined behavior triggered by invalid bytecode?

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 498 bytes --]

Noam Postavsky <npostavs@gmail.com> schrieb am Di., 22. Mai 2018 um
16:40 Uhr:

> On 22 May 2018 at 10:04, Philipp Stephani <p.stephani2@gmail.com> wrote:
>
> > That refers only to calling bytecode objects, not to e.g. reading their
> > printed representation. Would it also apply to reading or other forms of
> > handling bytecode objects? If so, the documentation should say so.
>
> Oh, you meant just reading the object causes a crash? That sounds like a
> bug.
>

OK, I've reported it as such.

[-- Attachment #2: Type: text/html, Size: 866 bytes --]

Re: How much do we care about undefined behavior triggered by invalid bytecode?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Nevertheless, IMHO the bytecode interpreter should be made robust where
  > possible.

I think it would be an improvement to do check for nonsensical
bytecode when creating a bytecode object.  As long as it doesn't make
reading a compiled file much slower.


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How much do we care about undefined behavior triggered by invalid bytecode?

[Tom Tromey]

>>>>> "Paul" == Paul Eggert <eggert@cs.ucla.edu> writes:

Paul> We could fix this problem by verifying that a series of bytecodes
Paul> cannot make Emacs crash, before allowing the bytecodes to be
Paul> executed. But wouldn't that be a reasonably large project?

FWIW on my more experiment JIT branch, I have a small bytecode verifier.
I needed it for the JIT, so it only does what I needed there, namely:

* Checking that the bytecode doesn't fall off the end
* Checking that the stack doesn't over- or underflow
* Checking that the stack depth at any given PC is a constant
* Checking that only valid opcodes are used
* Checking that the hash table given to Bswitch has only integer PC
  values and that they are in range

I don't know how hard it would be to extract this from the JIT.  Not too
bad maybe.

The other issue would be when to run it.  Maybe it would work to do it
the first time a bit of bytecode is executed.

Tom