feature: deobfuscating track names

[cphlipot1]

Context

For various reasons, apps may choose to obfuscate the names of trace events, and thus need to be deobfuscated to be readable by a human.

Currently perfetto allows for deobfuscating slice names in traces by appending a packet with SliceNameTranslationTable: https://perfetto.dev/docs/reference/trace-packet-proto#TranslationTable

This allows deobfuscating slice names. However, some tracks, particularly async tracks, inherit their default track name from the slice names. This causes obfuscated names to appear in tracks with no way to remove them.

Proposal

I propose we extend the TranslationTable proto linked above to have a new field that allows for deobfuscation of track names as well. I think we should also limit this to deobfuscating the names of async tracks only to avoid potential false positive matches against thread names.

[LalitMaganti]

The proposal seems intuitively reasonable but there are a lot of subtle points to take into account:

1. The idea to only address non-thread tracks makes sense but there are a lot of track types in trace processor apart from just thread/process async tracks: see https://cs.android.com/android/platform/superproject/main/+/main:external/perfetto/src/trace_processor/importers/common/track_tracker.h
   Which one of these types should we address? Just process? Process and global? Everything?
2. Should we only handle only events coming from TrackEvent or from all sources? For SliceTracker, we actually map all event sources but this might not be appropriate for tracks.
3. Or should we scrap all the above and maybe reuse the slice deobfuscation logic for tracks as well when we use the slice name as the track name? That would simplify things a lot and remove edge cases but may not be flexible enough for what you want.

Note also that that you should prepend the translation packet not append it: appending will work until you collect long (write_into_file) traces at which point it will subtly break in the current implementation :)

[LalitMaganti]

cc-ing @aMayzner to keep her in the loop on this too.

[cphlipot1]

The idea to only address non-thread tracks makes sense but there are a lot of track types in trace processor apart from just thread/process async tracks. Which one of these types should we address? Just process? Process and global? Everything?

Thanks for pointing out the various track types. for context, i was hoping to cover at least the following cases:

• track_event begin/end Tracing SDK apis.
• ATRACE_ASYNC_* (Track name is implicitly specified through slice name)
• ATRACE_ASYNC_FOR_TRACK_* (Track name is EXPLICITLY specified through the API)

I think those will all show up as process_tracks, i think translating those should be sufficient. AFIK it is not possible for ATrace to emit global tracks, but i'm unclear if that is possible to do via the Tracing SDK or not.

Should we only handle only events coming from TrackEvent or from all sources? For SliceTracker, we actually map all event sources but this might not be appropriate for tracks.

Mentioned above, but i think the same logic makes sense to apply for other data sources like atrace as well.

Or should we scrap all the above and maybe reuse the slice deobfuscation logic for tracks as well when we use the slice name as the track name? That would simplify things a lot and remove edge cases but may not be flexible enough for what you want.

I think this still might be good behavior to have and would help many, bot not all cases. There are several cases this won't work fully, where the track is given a name explicitly that is obfuscated either through TrackDescriptor name or via ATRACE_AYNC_FOR_TRACK APIs.

I can see both explicit and implicit track renaming able to coexist though without causing issues.

Note also that that you should prepend the translation packet not append it: appending will work until you collect long (write_into_file) traces at which point it will subtly break in the current implementation :)

Thanks! good to know. I'll keep that in mind :)

[LalitMaganti]

I think those will all show up as process_tracks

Yup you're correct, those are all process tracks

i'm unclear if that is possible to do via the Tracing SDK or not.

AFAIK (unless I'm misremembering) yes it's possible.

I think this still might be good behavior to have and would help many, bot not all cases.

Ack makes sense.

Given you only care about process scoped tracks for now, I'd restrict any changes to just process scoped tracks. I'd suggest doing the following:

1. Add a new "ProcessTrackNameDeobfuscation" packet which looks very similar to the current SliceName deobfucation packet
2. Change TrackTracker's logic to use this for all Process scoped tracks (note that counter tracks would also probably be changed)
3. Change TrackEventTracker::GetDescriptorTrackImpl which, for complicated reasons, does not set the track name until a bit later

Are you planning on sending a patch to support this? :)

[cphlipot1]

Sounds good, and sure, I can spend some time working on a patch for this.

[cphlipot1]

submitted https://android-review.googlesource.com/c/platform/external/perfetto/+/3079666 to address this