Closed vobst closed 10 months ago
As I see it, there are four possible solutions here:
if
, or stick with the first preimage, i.e., if
and continue
dict[int, str | list[str]]
dict[int, list[str]]
My thoughts on those are:
To me option 2 seems to be the lesser evil as those strings are equivalent from C's perspective so it shouldn't matter which one is returned. However, I would keep the if an output a debug log message so people can figure out what is going on.
However, I've got no clue about the context of the larger code base so I might be missing something here. Happy to hear some feedback :)
So the point of the function is to generate a map, so that if we have a value, we can look-up what it means. That appears to be the only place it's used, and it is private, so the only public expose is through the lookup
function. However, it feels problematic to change the API for what is a so-far, extremely uncommon situation, so I'd prefer to rule out lookup
potentially returning a list (it would have to always return a list, handing back different types creates an unstable API and leads to way more problems than just a break on a once-in-a-blue-moon event).
So the real options open to us are:
I'm kind of ok with any of them. I tend to err on the side of barfing rather than deciding things for the user, but that may work out to be extremely inconvenient, in which case my second choice would just be to ignore duplicates and debug log for the user. I'll mock up a PR that would make the change...
Commit
bpf: Implement cgroup storage available to non-cgroup-attached bpf progs
merged in Linux 6.2-rc1 introduced a duplicate enum value inenum bpf_map_type
.Currently Volatility throws an exception in that case, could we maybe handle it more gracefully, e.g., by making the mapping
int -> str | list[str]
orint -> list[str]
?The relevant code seems to be here and it looks like the problem was already anticipated ;)
https://github.com/volatilityfoundation/volatility3/blob/713b5f96dd218eea9c3fdb490a2436a474d22352/volatility3/framework/objects/__init__.py#L599C19-L599C19