AbortableThread

[ackava]

Thread.Abort is Dangerous

We agree and it is dangerous for anyone else to abort the thread one has started without any ownership. So why can't we make AbortableThread (AbortableTask which will run on AbortableThread pool). So owner who has created AbortableThread can control and abort the thread if need be. Script executions require AbortableThread.

Here are some practical use cases.

1. .NET core in production utilizes variety of libraries and third party frameworks. Today if due to any bug or any malicious attempt (script execution like Roslyn's CSharpScript.EvaluateAsync, simple while(true); can bring down entire app. As this thread will eat up all of CPU time and there is no way to stop this without killing and restarting entire app.
2. Roslyn is useful tool to allow extending application, but if we can't Abort the running script, it is again a blocking issue. When I am going to allow another user to write code, Even if I pass CancellationToken, I have no way to check if user is using it correctly. And if we have to run external CSharp script in a different process, then all benefits of InProcess execution goes away. We have to spend more time in creating inter process communication (thus building a micro service eventually) even when we don't need it.
3. In case of bug, sometimes logic isn't simple, variety of complicated logic can result in infinite loop which will result in blocking CPU. In this case, we have no way to identify what caused it? As We have to simply kill it and analyze through logging.
4. And in case of malicious attempt, Hacker won't be respecting CancellationToken.

NodeJS and Chrome does it

RunInContext , Consider a web browser, script taking long will be aborted and browser will return an error to user that script has timed out. Whole browser doesn't crash or need to be restarted.

How to Sandbox CPU time?

Point here is not about sandboxing security or anything else, when we allow some other's code to be executed, I want to put a timeout, and when I am trying to execute it, will be aware of consequences. CancellationToken does not sandbox CPU time.

ASP.NET Had this ability

1. We are still using ExecutionTimeout
2. And it makes sense to introduce ExecutionTimeout with ability to abort rather than introduce separate process execution and bring down whole process if only one single task is blocking CPU.

AbortableThread

AbortableThread can allow registering IDisposable by creator, so creator can register unmanaged resources, locks that will be safely released without ignoring ThreadAbortedException.

public delegate void AbortableThreadDelegate(ICollection<IDisposable> list, object state);

var thread = new AbortableThread((list, state) => {
    // I can safely run a long code...
    // register disposables...
});
thread.Start();

When thread exists or aborted, all registered IDisposable on list will be disposed safely. Creator can also check if the thread aborted safely or not.

This also leaves all safety issues as it is, we are not allowing all threads to be aborted, only the one who has created the thread can abort it. Thread.Current.Abort() should throw an exception Thread is not AbortableThread.

[svick]

.Net 7 added ControlledExecution.Run, which sounds very close to what you're looking for, except it's not meant for production code.

[Clockwork-Muse]

Even if I pass CancellationToken, I have no way to check if user is using it correctly.

This is/was true for libraries in the base runtime, at least in the way you're thinking of.
There's far more issues "around" whatever you might expect the behavior to be.

Generally the current recommendation for most of your use-cases has been "run it as a separate process", which also means cleanup does happen.

And in case of malicious attempt, Hacker won't be respecting CancellationToken.

If I provide you truly malicious code, you aborting the thread is going to happen "too late". I have far better ways to mess up your setup than just busy-waiting.

[ackava]

I forgot to provide more context, I am talking about scripting access, like running CSharp.EvaluteAsync. When I will be running a script, I will sandbox it, separate process is very expensive for small many scripts. Please check updated description.

[davidfowl]

It has nothing to do with opting into "abortableness", it's that code written in these constructs must always be hardened so that aborts don't corrupt the internal state. .NET has removed most of the code that tries to harden corruption against thread aborts. It's not pay for play.

[ackava]

I agree, but is it possible to have separate github repo with some native binding, a separate Nuget Package just for AbortableThread, one can use it independently. I tried to look source in .NET framework but its an external implementation Thread.Abort . Or it is not possible as an external library?

[aromaa]

It's not enough to just implement the APIs. It requires the libraries to be hardened against async exceptions or otherwise they could leave the process in unstable state and lead to corrupted data or crash the whole process. The CoreLib used to have "important code" inside finally blocks which are guaranteed to be executed even in the case of thread abort. This is no longer the case as code is written in a manner that assumes thread aborts are impossibility and there was a huge cleanup years ago to remove these finally blocks.

There are even JIT optimizations around this, like dotnet/coreclr#8949 which optimizes out these finally blocks from legacy code.

Its not just about whatever the user code is aborted but whatever the runtime code like JIT, GC or the CoreLib is being executed on when the thread abort happens.

[aromaa]

Also to note, if you wrap your malicious code inside the finally block, you can bypass the thread abort mechanisms. So even Thread.Abort might not be enough because the finally cleanup used to be always executed.

[ackava]

@aromaa I understand the issues now, how about recursively throwing AbortException till the stack reaches zero. I can see that user can inject while(true); even in case of finally, so we introduce AbortException again after little timeout.

[aromaa]

The fundamental problem is that the CoreLib is no longer hardened against thread aborts. For example commit c58629f removes some of those protections. That commit particularly is small but there were many more instances of them, I just can't seem to find it at quick glance. Some code has to execute in case of rude abort so that the CoreLib doesn't corrupt which is important for stability of the runtime. If the runtime instabilities even the code that aborts the thread is at risk of getting corrupted. Also to note that some resources might to start leaking.

The contract is that finally blocks will execute to completion even in the case of thread abort. So no matter what code and how much code is running inside it, the thread will not abort until it completes fully. You can't break this contract so that CoreLib can successfully clean up its state, no matter what. This means that if the malicious code is running while(true) inside a finally block it will never abort the thread. You can try this with .NET Framework. So trying to stop malicious code with thread abort is bad practice. It simply doesn't work.

[fbrosseau]

The only way to guarantee that arbitrary code behaves nicely - and to have the option of aborting it abruptly under some condition - is to move that code to a secondary process. This is true for Windows and this is true for Linux.

(I am disregarding the fact even process isolation would not be sufficient as a security boundary if you were to be considering multi-tenancy, but your original solution was in-proc so that should not be one of your concerns).

If your solution involves "run any user-provided code as-a-service", process isolation will be much more robust than anything you could ever achieve in-process, from any possible crash or corruption. Furthermore, offloading to a worker process would allow you to cap resources (Max CPU%, max memory, etc) at the kernel level - using jobobjects if Windows or cgroups if Linux.