Open sharvilshah opened 4 years ago
Reading this, it seems weird to have this both in power_sensors
and smc_keys
.
@directionless previous discussion regarding that here: https://github.com/osquery/osquery/issues/1854
Ah. Thanks for the context.
Yeah, it looks like we're missing types -- https://github.com/osquery/osquery/blob/4f78848794cd2df1532b9c8d7e3fe4b17dde3e2a/osquery/tables/system/darwin/smc_keys.cpp#L381-L404
Probably a good thing to add to CI
Any progress on this? I look a quick look and I'm not sure how to convert the hex values to floats (is there a common pattern for this?)
I think so...the spXY
values are always 2 bytes and it seems to be signed fixed point, where the MSB is the sign bit followed by X integer bits and Y fractional bits.
sp87
would be S I I I I I I I I F F F F F F F
I think. Need to try it out though.
Not sure how flt
is represented. Perhaps single precision float?
I dug at this s bit over a month ago. I did not find official docs, but I did find several implementations that had pretty clean parsers for this. I saw implementations based on lookup table, as well as a try repeatedly model.
I did not get to testing any of this, so it's something closer to a linkdump:
Stumbled upon this today (mostly due to a user asking on Slack).
From the quick look, I could see that we are missing the flt
type and that we are sometimes incorrectly comparing the type string, because it seems that all types are 4 bytes padded with spaces, so if the type is 3 characters, the last is a space.
We are comparing ui8
with ui8
, so that comparison fails, and at least in the smc_keys
table we display the values as hex. A similar problem would exist for flt
.
Also a flt
value is just a 4 byte float when unhexed, so a memcpy into a float
type seems to be enough.
EDIT: I also haven't fully analyzed the code but it seems that in power_sensors
we are using the values of the SMC keys that we convert to string for smc_keys
; while using another table to make another function is not always ideal, this case should be just a case of direct copying the values, but it seems that for smc_keys
we don't support decoding the same set of types than power_sensors
, so there are some values that we have to unhex.
I think the whole logic should be shared, meaning, smc_keys
is the table that gets the support for all types, and then power_values
just takes the correct rows that match the key it's interested in, and direct copy the output string of the column, with no conversion in between.
Bug report
power_sensors
table returns-1.00
value for all power related SMC keys, instead of actual values.Joining with
smc_keys
table, we can see that the raw SMC data is still there:This suggests that we may not be converting the various SMC data types correctly. I will dig deeper on this later.
What operating system and version are you using?
This is seen on 10.13, 10.14 and 10.15
What version of osquery are you using?