Project

General

Profile

Bug #12922

bhyve vmm ops could have stronger guardrail

Added by Patrick Mooney about 1 month ago. Updated 26 days ago.

Status:
Closed
Priority:
Low
Category:
bhyve
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

When bhyve is initialized, it chooses a vmm_ops set, based on the physical CPU (Intel or AMD) it's running on. The macros which call into this struct have explicit checks for it being non-NULL, which should never be possible given our guards anyways. To simplify those macros and maintain the safety, we could populate a null-ish vmm_ops struct with functions that simply panic.

History

#1

Updated by Patrick Mooney about 1 month ago

This is just a minor clean-up, and considering it's already a well-protected error case, should not be at all visible to a system.

#2

Updated by Electric Monk about 1 month ago

  • Gerrit CR set to 771
#3

Updated by Patrick Mooney 30 days ago

I've tested this on AMD and Intel systems to confirm that bhyve loads properly and is able to start VMs without issue.

#4

Updated by Electric Monk 26 days ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

git commit b38fc3ed80ecaf16c46433e690e6f17495c5e179

commit  b38fc3ed80ecaf16c46433e690e6f17495c5e179
Author: Patrick Mooney <pmooney@pfmooney.com>
Date:   2020-07-13T17:20:06.000Z

    12922 bhyve vmm ops could have stronger guardrail
    Reviewed by: Andy Fiddaman <andy@omniosce.org>
    Reviewed by: Mike Zeller <mike.zeller@joyent.com>
    Approved by: Dan McDonald <danmcd@joyent.com>

Also available in: Atom PDF