Would it make sense for there to be connections between two threads that would look for compromised applications? E.g. what can be done in hardware to allow one thread to monitor another thread or process for "problems"?

On Wednesday, December 15, 2021 at 2:38:56 PM UTC-6, JimBrakefield wrote:
> Would it make sense for there to be connections between two threads that would look for compromised applications? E.g. what can be done in hardware to allow one thread to monitor another thread or process for "problems"?
<
You could provide an OS-level service that allows said observer to read the
CPU-cycle-counter of a specified task, or read what queue the task is residing.
I don't see HW doing anything here.
<
Whether the observer can do anything about it is an entirely other problem.
<
But what are you expecting to happen when a task happens to be "inactive" for 7 days
between runs ? 30 days ? 365 days ? And even here the task is performing "as desired" !
<
Now, if you go all pedantic:: it is possible to connect some observer to machine checks
that happen on a specified set of tasks by a combination of HW (machine check) and
SW (routing to observer). {You could also do this for a set of exceptions, too.

On 12/15/2021 12:38 PM, JimBrakefield wrote:
> Would it make sense for there to be connections between two threads that would look for compromised applications? E.g. what can be done in hardware to allow one thread to monitor another thread or process for "problems"?

Even if you could monitor another thread, how could you tell that it had
"problems"? i,e, what would you look for and how would you prevent
false positives?

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Wednesday, December 15, 2021 at 2:38:56 PM UTC-6, JimBrakefield wrote:
> Would it make sense for there to be connections between two threads that would look for compromised applications?
<
Consider the plight of the non-root users who do not have the capability of even
figuring out if they are running log4j, which applications are affected, and how
to shut them down ?
<
> E.g. what can be done in hardware to allow one thread to monitor another thread or process for "problems"?
<
What makes you think this poorly written piece of SW needs some kind of HW support ?
<
Also note:: another vote against the "security" delivered by Java.....

JimBrakefield <jim.brakefield@ieee.org> wrote:
> Would it make sense for there to be connections between two threads that
> would look for compromised applications? E.g. what can be done in
> hardware to allow one thread to monitor another thread or process for
> "problems"?

Some of my colleagues have proposed adding additional cores for this:
https://www.cl.cam.ac.uk/~tmj32/papers/docs/ainsworth20-asplos.pdf

But, as mentioned, the problem boils down to how you can detect compromised
applications, rather than the mechanism for do so. In this case the
compromise was downloading and executing code from the internet - by the
time the code (which was Java bytecode rather than CPU instructions) hit the
CPU its provenance of being sourced from the internet was long lost.

There's work about provenance tracking based on memory tags:
http://ic.ese.upenn.edu/pdf/pump_hasp2014.pdf

which in theory might have caught that (MacOS for example has metadata on
files as to whether they came from the internet), but only if someone
followed through on a suitable policy. And it's not clear that such a
policy wouldn't have false positives.

(paying 100% overhead for every pointer would also get a ...certain
degree... of pushback from CPU vendors, apart from in niche applications)

Theo

Le 16/12/2021 à 01:39, MitchAlsup a écrit :
> On Wednesday, December 15, 2021 at 2:38:56 PM UTC-6, JimBrakefield wrote:
>> Would it make sense for there to be connections between two threads that would look for compromised applications?
> <
> Consider the plight of the non-root users who do not have the capability of even
> figuring out if they are running log4j, which applications are affected, and how
> to shut them down ?

Indeed.

>> E.g. what can be done in hardware to allow one thread to monitor another thread or process for "problems"?
> <
> What makes you think this poorly written piece of SW needs some kind of HW support ?

Very funny proposal indeed.

> Also note:: another vote against the "security" delivered by Java.....

Yes, that's a whole topic in itself.
But the "fun" part here is the ubiquitous use of libraries without
actually knowing what they really do. Very concerning. (Oh and don't get
me started on the obsession for logging that most Java developers seem
to have. It's amazing. They'll just want to log whatever they can, just
in case it proves useful. In many cases, it ends up being a resource
hog, or even a security threat as in this case, and the overall
usefulness of logging everything without giving it a second thought is
more that dubious.)

On 12/15/2021 4:39 PM, MitchAlsup wrote:
> On Wednesday, December 15, 2021 at 2:38:56 PM UTC-6, JimBrakefield wrote:
>> Would it make sense for there to be connections between two threads that would look for compromised applications?
> <
> Consider the plight of the non-root users who do not have the capability of even
> figuring out if they are running log4j, which applications are affected, and how
> to shut them down ?
> <
>> E.g. what can be done in hardware to allow one thread to monitor another thread or process for "problems"?
> <
> What makes you think this poorly written piece of SW needs some kind of HW support ?
> <
> Also note:: another vote against the "security" delivered by Java.....

And a vote against the "security" delivered by open source software. :=(

--
- Stephen Fuld
(e-mail address disguised to prevent spam)