
Reviewing Microsoft's Automatic Insertion of Telemetry into C++ Binaries - osopanda
https://www.infoq.com/news/2016/06/visual-cpp-telemetry
======
jongalloway2
People commenting here apparently haven't read the comment @cremno linked to:

> Lots of things inside Windows emit ETW events, which is Windows equivalent
> of DTrace (basically the entire OS, and .NET), it's super useful for
> debugging performance related events. It's not "Telemetry" like Google
> Analytics, it's for _you_ to debug your own programs. The easiest way to
> view the output of them is via WPA, you can watch some videos about it at
> [https://msdn.microsoft.com/en-
> us/library/windows/hardware/hh...](https://msdn.microsoft.com/en-
> us/library/windows/hardware/hh448170.aspx)

[https://news.ycombinator.com/item?id=11652077](https://news.ycombinator.com/item?id=11652077)

~~~
vardump
>> Lots of things inside Windows emit ETW events, which is Windows equivalent
of DTrace

It'd be less wrong to say "like Windows equivalent of syslog".

ETW is nowhere near as sophisticated as DTrace. ETW is more or less a simple
logging subsystem, it's not actually modifying any code in memory to
_dynamically_ (that's what that _D_ is for) insert instrumentation.

So if something is not compiled to emit ETW events, ETW can't trace it at all.

DTrace can trace anything that runs on the system. No need for binaries to
emit any events.

~~~
ksk
> it's not actually modifying any code in memory to dynamically (that's what
> that D is for) insert instrumentation.

First of all, it is impossible to instrument a random binary on the fly
without private symbols. Even otherwise, DTrace requires instrumentation to be
inserted in user code. Without it, it will only get data from built in probes
in the OS libraries/kernel/etc. (Same as ETW)

>So if something is not compiled to emit ETW events, ETW can't trace it at
all.

This is false. I don't know if you've ever used ETW but I use it regularly to
run traces on binaries that don't have any ETW specific instrumentation.

~~~
vardump
> First of all, it is impossible to instrument a random binary on the fly
> without private symbols.

That's not true. You can use DTrace instrumentation on any binaries. It's more
effort, of course, to figure out what address is what. You can work backwards
from system calls to get some reference point about target process data
structures. And of course trace obvious things such as function entry points,
particular instructions, etc.

Also other dynamic binary tracing frameworks can do tracing without symbols.

~~~
ksk
>> It's more effort, of course, to figure out what address is what.

Um.. at that point you're pretty much making your own symbols. So I don't know
what your point is.

~~~
vardump
Is it a phonebook when someone finds out and scribbles down phone numbers for
a few people?

~~~
ksk
I don't think you get it. Getting the address of the function call and
capturing the entire call stack of a running process is trivial. It has been
possible to do this for decades on all platforms where the ABI is known.
Knowing what address belongs to which function, knowing the type of the
parameters, return values, etc, requires a ton of effort. But I could be
wrong. Can you point to any common usecase of dtrace where people use it when
no debugging symbols and no providers are present in the user code and
everything has to be reverse engineered? I'm not going to bother with inlined
functions and the like - which would be unfair for any tool to automatically
know about.

------
ryuuchin
They could probably get away with keeping it but turning it into an off by
default feature. Renaming the linker object file into telemetry.obj (or
something entirely different) to enable it. It seems as though it wasn't
really used though so I guess with the public outcry they just decided to axe
it and be done with it.

------
plexchat
Old news. See
[https://www.reddit.com/r/cpp/comments/4ibauu/visual_studio_a...](https://www.reddit.com/r/cpp/comments/4ibauu/visual_studio_adding_telemetry_function_calls_to/d30dmvu)

~~~
0x0
It's new news that they are now removing it.

But even while they changed their minds, with a display of lack of judgment
like this, who will trust their compilers anymore?

~~~
MaulingMonkey
> who will trust their compilers anymore?

Me.

Microsoft has some real issues with regards to privacy, security, and
performance. An ETW event on main entry/exit is none of the above.

It's worth yanking from Microsoft's POV because "Telemetry" is a big bad scary
word, but from my POV it's a pointless distraction from actual privacy,
security, and performance concerns.

C'est la vie...

------
canada_dry
I can't be the only one who finds it a bit (actually very) scary that just a
little wire brushing things like this are uncovered. When I also read about
things like MS's secretive constant-calling-home and Intel's secretive IME
(the "ultimate rootkit") I get very worried about the real state of personal
privacy nowadays.

------
BugsBunnySan
So, it has come to this:
[https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...](https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf)
(Ken Thompson "Reflections on Trusting Trust") in real life...

