Delayed notice again #12805

iluuu1994 · 2023-11-28T00:51:36Z

This is another attempt to delay warnings (see #12090).

This attempt implements an idea from @bwoebi to completely avoid the RT_CONSTANT issue by copying constant zvals to EG. This solution simplifies the implementation a lot and makes this feasible again.

@dstogov Are you happier with this approach? If so, I will see what changes are necessary for JIT.

This is a prototype for fixing a long-standing source of interrupt vulnerabilities: A notice is emitted during execution of an opcode, resulting in an error handling being run. The error handler modifies some data structure the opcode is working on, resulting in UAF or other memory corruption. The idea here is to instead collect notices and only process them after the opcode. This is implemented similarly to exception handling, by switching to a ZEND_HANDLE_DELAYED_ERROR opcode, which will then switch back to the normal opcode stream. Unfortunately, what this prototype implements is not sufficient. Opcodes that acquire direct (INDIRECT) references to zvals require that no interrupts occur between the producing and the consuming opcode. Chains of W/RW opcodes should be executed without interrupt. Currently, the notice is only delayed until after the first opcode, which still results in an illegal interrupt (bug78598.phpt shows a UAF with this change). I'm not sure how to best handle that issue.

bwoebi · 2023-11-28T01:54:46Z

Zend/zend.c

+	info->message = zend_vstrpprintf(0, format, args);
+	va_end(args);
+
+	zend_hash_next_index_insert_ptr(&EG(delayed_errors), info);


I guess a single linked list in zend_error_info would be more straightforward than using a hashtable for that.

It's used as a stack, essentially, and avoids an allocation for each warning. Should I use zend_stack instead?

bwoebi · 2023-11-28T02:29:02Z

Zend/zend_vm_def.h

+			break;
+	}
+
+	// FIXME: Is this guaranteed to be there?


For the locations where a delayed error may be thrown currently, yes.
We might want to simply ZEND_ASSERT(next_op < EX(func)->op_array.opcodes + EX(func)->op_array.last)?

It's probably ok to just check, this handler is part of a slow path, and not intended to be particularly fast.

dstogov

I don't see how this will work with JIT.
Can this approach solve ALL the user_error handler related problems?

dstogov · 2023-11-28T08:16:09Z

Zend/tests/bug52041.phpt

+--INI--
+opcache.jit=0


Why do you disable JIT. Its not supported yet?

Yes, JIT doesn't seem to work but I have not looked into where it goes wrong.

dstogov · 2023-11-28T08:31:32Z

Zend/zend.c

+
+	if (EG(current_execute_data)->opline != EG(delayed_error_op)) {
+		EG(opline_before_exception) = EG(current_execute_data)->opline;
+		EG(current_execute_data)->opline = EG(delayed_error_op);


How do you like to implement this branch in JIT?
Note that you might need to save all data kept in CPU registers before branching.
The jump back from delayed warning to normal control flow is not possible at all.

Oh... I assumed JIT handled exception the same way as the VM, checking EX(opline) rather than EG(exception). It also calls the EG(exception_op)->handler directly, rather than looking up EX(opline)->handler. That indeed will not work here.

The jump back from delayed warning to normal control flow is not possible at all.

I will have to look more closely how this works for exceptions to understand what changes are required. I assumed exceptions trigger deoptimization but I guess that's not correct.

dstogov · 2023-11-28T08:41:38Z

Zend/zend_vm_def.h

+		zend_op *delayed_op = &EG(delayed_error_op)[0];
+		*delayed_op = *next_op;


In case you have few FETCH instructions in row and few of them produce warnings, then EG(delayed_error_op)[0] is going to be overridden few times. Is it OK?
Will this work in conjunction with magic __get() and different warnings in main code and magic methods?

In case you have few FETCH instructions in row and few of them produce warnings, then EG(delayed_error_op)[0] is going to be overridden few times. Is it OK?

Yes. The idea is that each instruction producing indirect values only delays to the next opcode. If that opcode also produces an indirect value, then it wil once again set EG(delayed_error_op)[0] to the instruction after that, until eventually the indirect value is used and the error can be emitted.

Note that this happens only if the first FETCH emits a warning. The error is still delayed until the fetch+assign chain.

Will this work in conjunction with magic __get() and different warnings in main code and magic methods?

I didn't test this, but I think one unexpected things could be that we don't associate EG(delayed_errors) with a particular stack frame. If the magic method produces a warning, pending warnings from the outer VM call will also be handled. This could be solved by storing the execute_data on the delayed error, and only handling those belonging to the current one. Apart from that I believe magic methods should work correctly with this approach.

iluuu1994

Can this approach solve ALL the user_error handler related problems?

I think this should solve all the issues we've experienced lately, for every warning that is actually delayed. I'm not sure yet which warnings require delaying. There's the obvious BC break where previously set_error_handler could abort the operation half-way through, whereas after this PR it could only abort control flow once the current handler has finished. Of course, there are some warning where this is undesired (e.g. function deprecations) that should continue being emitted before the operation starts.

Depending on whether you think JIT can be implemented without massive effort, I will take a look at what warnings need to be changed.

iluuu1994 · 2023-11-28T11:24:38Z

Zend/tests/bug52041.phpt

+--INI--
+opcache.jit=0


Yes, JIT doesn't seem to work but I have not looked into where it goes wrong.

iluuu1994 · 2023-11-28T14:34:52Z

Zend/zend.c

+
+	if (EG(current_execute_data)->opline != EG(delayed_error_op)) {
+		EG(opline_before_exception) = EG(current_execute_data)->opline;
+		EG(current_execute_data)->opline = EG(delayed_error_op);


Oh... I assumed JIT handled exception the same way as the VM, checking EX(opline) rather than EG(exception). It also calls the EG(exception_op)->handler directly, rather than looking up EX(opline)->handler. That indeed will not work here.

The jump back from delayed warning to normal control flow is not possible at all.

I will have to look more closely how this works for exceptions to understand what changes are required. I assumed exceptions trigger deoptimization but I guess that's not correct.

iluuu1994 · 2023-11-28T14:51:14Z

Zend/zend_vm_def.h

+		zend_op *delayed_op = &EG(delayed_error_op)[0];
+		*delayed_op = *next_op;


In case you have few FETCH instructions in row and few of them produce warnings, then EG(delayed_error_op)[0] is going to be overridden few times. Is it OK?

Yes. The idea is that each instruction producing indirect values only delays to the next opcode. If that opcode also produces an indirect value, then it wil once again set EG(delayed_error_op)[0] to the instruction after that, until eventually the indirect value is used and the error can be emitted.

Note that this happens only if the first FETCH emits a warning. The error is still delayed until the fetch+assign chain.

Will this work in conjunction with magic __get() and different warnings in main code and magic methods?

I didn't test this, but I think one unexpected things could be that we don't associate EG(delayed_errors) with a particular stack frame. If the magic method produces a warning, pending warnings from the outer VM call will also be handled. This could be solved by storing the execute_data on the delayed error, and only handling those belonging to the current one. Apart from that I believe magic methods should work correctly with this approach.

iluuu1994 · 2023-11-28T14:51:53Z

Zend/zend_vm_def.h

+			break;
+	}
+
+	// FIXME: Is this guaranteed to be there?


It's probably ok to just check, this handler is part of a slow path, and not intended to be particularly fast.

iluuu1994 · 2023-11-28T14:53:30Z

Zend/zend.c

+	info->message = zend_vstrpprintf(0, format, args);
+	va_end(args);
+
+	zend_hash_next_index_insert_ptr(&EG(delayed_errors), info);


It's used as a stack, essentially, and avoids an allocation for each warning. Should I use zend_stack instead?

nikic and others added 2 commits November 28, 2023 00:34

Add support for INDIRECT delaying

198b22a

github-actions bot added Category: Engine Extension: opcache labels Nov 28, 2023

bwoebi reviewed Nov 28, 2023

View reviewed changes

dstogov reviewed Nov 28, 2023

View reviewed changes

iluuu1994 commented Nov 28, 2023

View reviewed changes

iluuu1994 mentioned this pull request Mar 19, 2024

Array assignment fails when the array has been resized in error handler #13754

Open

iluuu1994 mentioned this pull request Sep 17, 2024

Assertion failure in Zend/zend_compile.c #15907

Closed

iluuu1994 mentioned this pull request Nov 8, 2024

Heap Use-After-Free (UAF) Bug in PHP #16726

Open

arnaud-lb mentioned this pull request Jan 9, 2025

Assertion failure Zend/zend_hash.c:1543 #17416

Open

iluuu1994 mentioned this pull request Mar 13, 2025

ternary reference assignment should be legal #18043

Open

arnaud-lb mentioned this pull request Apr 9, 2025

assertion failure spl_fixedarray #18274

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Delayed notice again #12805

Delayed notice again #12805

iluuu1994 commented Nov 28, 2023

bwoebi Nov 28, 2023

iluuu1994 Nov 28, 2023

bwoebi Nov 28, 2023

iluuu1994 Nov 28, 2023

dstogov left a comment •

edited

Loading

dstogov Nov 28, 2023

iluuu1994 Nov 28, 2023

dstogov Nov 28, 2023

iluuu1994 Nov 28, 2023

dstogov Nov 28, 2023

iluuu1994 Nov 28, 2023

iluuu1994 left a comment

iluuu1994 Nov 28, 2023

iluuu1994 Nov 28, 2023

iluuu1994 Nov 28, 2023

iluuu1994 Nov 28, 2023

iluuu1994 Nov 28, 2023

		zend_op *delayed_op = &EG(delayed_error_op)[0];
		delayed_op = next_op;

		--INI--
		opcache.jit=0

		--INI--
		opcache.jit=0

Delayed notice again #12805

Are you sure you want to change the base?

Delayed notice again #12805

Conversation

iluuu1994 commented Nov 28, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dstogov left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

iluuu1994 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dstogov left a comment •

edited

Loading