Linux: Kmsg Unsupported kernel implementation - 3.2 #1066
Comments
|
Hi, just passing by on the issue :) I found that Here is the definition diff :
Regarding the 3.2 definition, isn't edit: there is also an intermediate implementation here : https://elixir.bootlin.com/linux/v3.10.108/source/kernel/printk.c#L251 ( |
|
That makes sense @Abyss-W4tcher - thanks for digging into it. I guess we need to add an extra option into to pull out the entries in this case. |
|
Hello @gcmoreira and @ikelos - thanks so much for looking into this. After this fix I still can't run the plugin. It looks like Taking a look in volshell it all looks like it should work - it's just the type that is causing issues: I'll see if I can make a little patch to work around this issue. I imagine its not like this in every ISF out there. |
|
@eve-mem thanks. That's interesting. Not sure why in your ISF those symbols are void, but it should be something wrong there as none of them are void in 3.2 or any other kernel version. Have a look at my ISF: "log_buf": {
"type": {
"kind": "pointer",
"subtype": {
"kind": "base",
"name": "char"
}
},
"address": 18446744071591553768
},
"log_buf_len": {
"type": {
"kind": "base",
"name": "int"
},
"address": 18446744071591553776
},
"log_end": {
"type": {
"kind": "base",
"name": "unsigned int"
},
"address": 18446744071593651540
},and >>> self.vmlinux.object_from_symbol(symbol_name="log_buf").vol.type_name
'symbol_table_name1!pointer'Have you generated the ISF with the latest dwarf2json version? |
|
Great question. A touch old! "producer": {
"name": "dwarf2json",
"version": "0.4.1"
},It's actually the samples from the vol foundation page linked from in the readme. You can get the ISF here: https://downloads.volatilityfoundation.org/volatility3/symbols/linux.zip I like to use that sample as I think it's used in the auto tests when commiting - it might be worth updating them? That's a separate issue completely though. Based on what you've showed in in printk I have no doubt if I remade the ISF with a later version it would work. I'll have a go at that when I can. Do you think it's worth a warning/debug message when using old ISF files in general or do we want to fight for backwards compatibility with older ISFs in ? I know there are other issue that were fixed with dwarf2json updates, so ISFs prior to that would never have worked anyway. Maybe it's possible to add a requirement for the ISF producer for a plugin, so that it would only work on version made by dwarf2json higher than x version? Would limit them to working only on ISFs made by dwarf2json though. (which I'm sure is 99.999% of all ISFs, apart from the odd one crafted by hand when you can't get debug symbols - but those users will probably be alright getting past a check like that.) What do you think? Could even do something a little hacky like this to point users in the right direction? It would only fix it for this particular issue rather than doing it generically though. diff --git a/volatility3/framework/plugins/linux/kmsg.py b/volatility3/framework/plugins/linux/kmsg.py
index d1f17bf9..d6a346bd 100644
--- a/volatility3/framework/plugins/linux/kmsg.py
+++ b/volatility3/framework/plugins/linux/kmsg.py
@@ -14,7 +14,7 @@ from volatility3.framework import (
renderers,
)
from volatility3.framework.configuration import requirements
-from volatility3.framework.objects import utility
+from volatility3.framework.objects import utility, Pointer
vollog = logging.getLogger(__name__)
@@ -213,6 +213,10 @@ class Kmsg_pre_3_5(ABCKmsg):
def run(self) -> Iterator[Tuple[str, str, str, str, str]]:
log_buf_ptr = self.vmlinux.object_from_symbol(symbol_name="log_buf")
+ if not isinstance(log_buf_ptr, Pointer):
+ raise TypeError(
+ f"The type of log_buf is {log_buf_ptr.vol.type_name} when a pointer is expected. This may
be due to a currupt symbols file or a symbols file created with an old version of dwarf2json."
+ )
log_buf_len = self.vmlinux.object_from_symbol(symbol_name="log_buf_len")
log_buf = utility.pointer_to_string(log_buf_ptr, count=log_buf_len)
log_end = self.vmlinux.object_from_symbol(symbol_name="log_end") |
@eve-mem I'm not sure why those ISFs have wrong symbol types. I will try to find out. |
Absolutely, we recently discussed this with @ikelos in one of the PRs and we agreed that's necessary. Not sure if @ikelos has any update with this. I haven't had the chance to take a look yet. |
Hmm, in my opinion, this seems to be an issue with the generated ISF. It needs to have the correct type; otherwise, we'll end up double-checking the types every time we use object_from_symbol(), accompanied by a warning message, which doesn't seem practical to me. Let's see what @ikelos thinks about it. |
Cool, anyway even if those samples are used in the "auto tests", they must be using different ISFs as the PR passed all the tests. |
|
Yeah - I think doing the hacking thing probably isn't a good idea but felt better than just plain crashing. Wouldn't want it to become the way to do it everywhere as you point out it would just mean checking every single time. These are the auto tests I mean, the github actions - https://github.com/volatilityfoundation/volatility3/actions/runs/7389566835/job/20102666191. There is probably a proper name for those tests - regression testing? The link is to the run where your PR get tested, I think it only runs a few of the linux plugins - and I don't think kmsg is one of them. I think it uses those symbols I linked to, you can see the wget in the logs too. I think we've proven that the kmsg plugin now should work if we've got the right ISF - so on that front I think it's all sorted. Thanks again for sorting it out so quickly. |
|
I remembered about @Abyss-W4tcher great collection of ISF which includes the exact one needed for this sample - https://github.com/Abyss-W4tcher/volatility3-symbols/blob/master/Debian/amd64/3.2.0/4/Debian_3.2.0-4-amd64_3.2.57-3%2Bdeb7u2_amd64.json.xz It's made with a more modern version of dwarf2json: {"producer":{"name":"dwarf2json","version":"0.6.0"},"format":"6.2.0"}And as expected your plugin works perfectly @gcmoreira: |
|
Ok, so we've got a few options:
So I think I'm leaning to the generic symbol table version checker. You can hand it a list of tables, or just get it to check them all, it allows the plugin to decide how to handle a failure, but it doesn't automatically protect all plugins, so you'd need to know which plugins are affected and add this too them. Still seems like the most straightforward without tinkering with the entire framework though? Then the question becomes where does this generic code live, would it be useful for windows? Actually, yeah, probably, so probably want it to live somewhere generic. I'm thinking either a method of the concrete Does that sound good to everyone? |
|
That sounds like it could be a really nice way to handle it. If i can help at all let me know. |
Thanks, let me give it a crack first and then you can tweak it if you want improvements to it... 5:) |
|
Sounds amazing. We can add the requirement checks as we encounter issues. Thanks @ikelos |
Describe the bug
When using the linux.kmsg on a 3.2 sample the plugin shows an error that it is unsupported kernel version.
This was spotted in #1055 but is a separate issue.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
kmsg is able to display some results.
We can see in this short snippet that at least some of the information is there in
__log_buf.The
symtab_checksforKmsgLegacylook forprintk_logwhich isn't in the ISF for this samplevolatility3/volatility3/framework/plugins/linux/kmsg.py
Lines 203 to 205 in 18e5d7a
In this sample it's also the case that
log_bufis still pointing at__log_buf. I'm not so sure on the whole dance around when__log_bufisn't used at the moment - but hopefully this is enough information to help someone look into it (I bet @gcmoreira knows exactly what is happening... 😄)The text was updated successfully, but these errors were encountered: