-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for basic chassis information #5282
Conversation
if (!wmiResults.empty()) { | ||
for (const auto& data : wmiResults) { | ||
Row r; | ||
bool boolean = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rename this :p Also auto
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I struggled to find a good name for this since it's so generic. Any ideas here? What if I just said "condition"? Or maybe "isPresent" ? That sounds very c# though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps an endrun, these seem to be more commonly represented as INTs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You know, revisiting this after a long hiatus made me realize "boolean" in this case relates to items in wmiResults, not a variable that is tracking if I want to bail out.
I'm renaming this to isPresent, because it will represent if a certain feature exists on the machine (wmiResults will have true/false for this field). If there's any thought on a better variable name, let me know.
Consequently, I'm going to add a bail condition to the for loop.
specs/windows/chassis_info.table
Outdated
implementation("chassis_info@genChassisInfo") | ||
examples([ | ||
"select * from chassis_info", | ||
]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
New line
Anything else I need to change? I'd like to upstream this by sometime early January if possible |
Oops, I forgot I let this one slip. Is there anything else I needed to change and any response wrt to the questions re: flipping the logic and returning early? |
@jjerger sorry we let this one slip! Any chance you could rebase this off of the latest master, make the "return early" changes suggested and we'll get this merged? Otherwise the code looked good to me. |
Oh man I totally forgot about this one. I can probably do that, just gotta
find the time. It's been busy on my end the last few months.
…On Sat, Sep 14, 2019 at 8:36 PM Nick Anderson ***@***.***> wrote:
@jjerger <https://github.com/jjerger> sorry we let this one slip! Any
chance you could rebase this off of the latest master, make the "return
early" changes suggested and we'll get this merged? Otherwise the code
looked good to me.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5282?email_source=notifications&email_token=AISPRFYHSF6R6WAD66HY72DQJWUT7A5CNFSM4GCED4I2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6XIOHQ#issuecomment-531531550>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AISPRF27PTJ53FMFRNJG2P3QJWUT7ANCNFSM4GCED4IQ>
.
--
* • **James Jerger*
* • **Technical Solutions Engineer*
* • *Google LLC
* • *[email protected]
• +1 425 655 4867
|
Holy cow I really need to get on this. Are we still okay to rebase off the master, flip the return early changes and get this merged? I can get moving on that. |
Yes. Rebasing on master is correct. Early returns are preferred. Happy to re-review with those. |
|
Ah, regarding CLAs, I left and rejoined Google in the time since I opened this, so I will need to re-link my github account to the org. I should have that handled in the next day or so. |
Hopefully two more steps and this is ready to go!
diff --git a/osquery/tables/system/windows/chassis_info.cpp b/osquery/tables/system/windows/chassis_info.cpp
index 3682cd80..c0e2e975 100644
--- a/osquery/tables/system/windows/chassis_info.cpp
+++ b/osquery/tables/system/windows/chassis_info.cpp
@@ -24,7 +24,7 @@ QueryData genChassisInfo(QueryContext& context) {
WmiRequest wmiSystemReq("select * from Win32_SystemEnclosure");
const auto& wmiResults = wmiSystemReq.results();
- //check if the results are empty and return a warning if so
+ // check if the results are empty and return a warning if so
if (wmiResults.empty()) {
LOG(WARNING) << wmiSystemReq.getStatus().getMessage();
return results;
@@ -41,7 +41,7 @@ QueryData genChassisInfo(QueryContext& context) {
r["chassis_types"] = INTEGER(number);
data.GetString("Description", r["description"]);
- //reset boolean to make sure there is no interference from the last call
+ // reset boolean to make sure there is no interference from the last call
boolean = false;
data.GetBool("LockPresent", boolean);
@@ -55,7 +55,7 @@ QueryData genChassisInfo(QueryContext& context) {
data.GetString("SKU", r["sku"]);
data.GetString("Status", r["status"]);
- //reset boolean to make sure there is no interference from the last call
+ // reset boolean to make sure there is no interference from the last call
boolean = false;
data.GetBool("VisibleAlarm", boolean); Or run the build target
|
Uh oh, I think i botched the rebase from your master (this feels familiar, thought I'd learned). Perhaps I'm best nuking the current branch and opening a PR under a fresh one properly rebased? |
You can push force, something like:
|
Ok after that mess of rebasing I think I have it current again and added an integration test. I haven't added one of those in ages, so please sanity check it to make sure I made the right assertions. |
@jjerger You can verify the formatting of the code via We also have EDIT: Check https://osquery.readthedocs.io/en/latest/development/building/ |
I set up a new Windows instance following those prereqs so it should have them all. I'll verify with that. |
Oddly enough clang format was formatting in a way that caused it to fail check, so that's interesting. I see Wix errors - is there a formatting command that needs to be done through Wix? I have no experience with that toolset and I didn't see much mention of it in the build doc (it's only used on Release build by the look of it?) |
Actually, checking the outupt it looks like Wix is missing from the test container? |
Is it? I see passing Wix tests:
|
Heads up I added a quick-fix since the integration test code was not being built. |
It seems to be failing on WmiRequest but I am not quite sure why.. I used the same logic as I had used in previous tables but chassis_info is returning false for wmiSystemReq.getStatus().ok() resulting in an empty result set. This isn't being caught in the build process but surfacing in the table integration check. Am I missing something here? |
Does the WMI query not work on a VM? If that is the case then the integration test should only apply the validation if there is a non-empty result set. |
I suppose it depends on the hypervisor, since GCP instances do return some info, although almost nothing. Maybe Azure doesn't? The part that got me thinking about this was The Windows Release Output indicating that the table didn't exist and that status.ok() was false. I figured this was referring to the query that built the table? When I moved it to a physical desktop and rebuilt it, I saw the same behavior. No error during build, but if I check osqueryi, there is no chassis_info table at all. Win32_SystemEnclosure is in the Root\CIMv2 namespace so we shouldn't have to specify it, right? |
…s_info cause I think it was also failing to retrieve the status
Looks like LGTM timed out running tests - not sure if they all pass. As it stands, let's hold off on merging too. I found an error with ChassisTypes that I'm addressing. |
Related to my previous comment: I see that WmiResultItem has a way to retrieve an array of strings with GetVectorOfStrings, but is there a similar way to retrieve integers? I'm having difficulty retrieving ChassisTypes as it is an array of UInt16 values, although I have not been able to find a device with multiple values contained within. Perhaps Surface Pros might have two with the detachable chassis? No idea. |
The LGTM test runner doesn't run long enough to compile osquery and all of its dependencies, so right now LGTM will always fail. |
Eek! I had not yet fixed an error with ChassisTypes. It'll run as is, but the value it's returning is less than helpful. Want me to open a separate PR with the fix to that? |
Yes please! |
…0 to master * commit 'eeee0fb0957f5af983f817c2e6f19c53108d9e09': (83 commits) Add additional changelog items (osquery#6523) Changelog for 4.4.0 (osquery#6492) build: Add Azure tables to specs CMakeLists (osquery#6507) CMake: Correct macOS framework linking (osquery#6522) tables: Only populate table cache with star-like selects (osquery#6513) CMake: Fix and cleanup compile flags (osquery#6521) docs: Add note to bump the Homebrew cask (osquery#6519) tests: Fix atom_packages, processes, rpm_packages flakiness (osquery#6518) bug: Do not use system proxy for AWS local authority (osquery#6512) packaging: updating docs on cpack usage to include Chocolatey (osquery#6022) bug: Fix typed_row table caching (osquery#6508) Implement event batching support for Windows tables (osquery#6280) http: Use sync resolve (osquery#6490) Add support for basic chassis information (osquery#5282) Only emit 'denylist' warning once (osquery#6493) docs: Remove references to brew in macOS install (osquery#6494) Fix for osquery#5890: Event Format Results and the Kafka Logger (osquery#6449) make apt_sources table parsing much more resilient (osquery#6482) Make file and hash container columns hidden (osquery#6486) Update documentation to use 'allow list' and 'deny list' diction (osquery#6489) ...
This will query basic chassis_information such as equipped alarms and breach status/description should there be one.
I have not yet included an integration test because I am not sure which fields to verify as not null - this WMI class can return alot of null values depending on what the chassis is equipped with. I was hoping for some input on what should be verified for this table to be considered sane as well as my approach to handling the boolean values (resetting a value each time for example).