-
Notifications
You must be signed in to change notification settings - Fork 236
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
Fuzzing bug fixes #3989
base: main
Are you sure you want to change the base?
Fuzzing bug fixes #3989
Conversation
Fix CICD build failures.
This reverts commit e7311fe.
…studio.com/eBPFForWindows/_git/eBPFForWindows into gtrevi/vm-extensipn-update
…dehub.visualstudio.com/eBPFForWindows/_git/eBPFForWindows into gtrevi/update-pipeline-for-vmextension
…o-Update requirements. This PR changes the following with the eBPF VM Extension: - Adds workarounds for handling the new Auto-Update requirements with the existing VM Platform context handling limitations: - The *Update command* now handles atomically the entire updating process. - Before running, the *Update command* backs-up the current installation (can be the initial WinPA provisioning, or from a previous VM Extension). - Adds handling of a local "Updating" persistent state (as a registry key), in order to compensate the lack of a global state handled by the VM Extension platform. - The *Update operation* will fail the overall update if restarting the GuestProxyAgent service fails and, upon any failure, it will attempt to rollback to the previous installation. >Background: although restarting the GuestProxyAgent service is an extended operation that is not part of the eBPF VM Extension's scope, we should account success/failure of this operation in the overall update status, so that the VM Agent will stop rolling out updates to Azure VMs. - Allows the update to downgrade the current installation only if in the context of a rollback. Any other downgrade attempt will fail the *Update operation*. - Adds more error return codes, defined in global constants for improved logging and troubleshooting. Related work items: #158377
I second this. As much as it is going to be painful to do, we should file each internally found bug in github, and fix them in the open. |
e5ab683
to
5a5a1c5
Compare
6b66335
to
9b89e9e
Compare
9b89e9e
to
f25b584
Compare
Issue #3998 is just a perf optimization according to that issue, and is apparently non-trivial, so should be separated from security bug fixes. The principle is that a fix for #4010 would be a backport candidate (e.g., to v.0.19.1) but a PR for #3998 would not be since it doesn't fix any security issue that affects production. |
0.19.1 already has these changes that are being merged to main. Without fix to 3998 first, many of the issues would not be even found, that this PR is fixing as otherwise the fuzz tests took too long to run and often timed out without finding any issues. Hopefully, this is the first and last time where we have to merge so many fixes together. Please resolve this comment so that we can get this important payload merged. |
Due to special circumstances we had to take these set of changes this way, after discussing with Microsoft security experts. Hopefully we will only rarely get security bugs, which we will fix according to the MSRC process. |
f25b584
to
b2d9aef
Compare
PR description is updated with more context and a new issue #4010 is created that lists all the defects found by fuzzing |
Description
This PR fixes #4010. These are a collection of bugs found by fuzz testing.
This PR also fixes #3992, #3998 and #4001.
Testing
New fuzz tests were added.
Documentation
No.
Installation
No.