https://github.com/osquery/osquery logo
Join Slack
Powered by
Hrm. As I tinkering around m1 things, I think we m...
# core
s
Hrm. As I tinkering around m1 things, I think we made it hard. We have pretty comprehensive support for platforms. They’re in the schema, we expose a bitfield of them. Etc. But we don’t expose any kind of architecture info. It’s not in 
osquery_info
. It’s not in the table schema. Etc.
s
cpu_type
from 
system_info
should have that iirc
or is that not what you mean?>
m
Well it's not on the website where the user wants to know why the table exists or doesn't exist for them, or why it's empty
I think we have a gap in ownership of the osquery website, there are a few things that could be improved about the schema view there
s
Maybe a gap in ownership, but I think it’s a gap in knowledge. To some degree, nothing has an owner, we’re a loose collective. But none of us are super knowledgable about js SPA stuff, so the website is a bit grotty.
☝️ 1
But I’m not thinking about the website. I’m thinking about the schemas. Kolide parses them, and tracks a lot of what-should-work where. But because osquery doesn’t really differenciante by arch, we hadn’t either. So now I’m grafting it on. But it’s imperfect.
cpu_type
from 
system_info
is (ideally) what the system is. But it is not what osquery was compiled for.
d
Out of curiosity, is there any table that works/doesn't work on a Linux with ARM architecture?
s
cpuid is intel specific. There may be others.
👍 1
m
Probably the tables that rely on SMBIOS https://github.com/osquery/osquery/issues/7588
s
SMBIOS works under Linux ARM, it’s only Apple M1 devices
🆒 1
8 Views
Open in Slack
PreviousNext
Powered by