Re: bhyve: passthrough SMART info from host nvme controller
> But as you point out, the only way to have that happen is to remove > capsicum, but that would make byhve overall LESS secure. Yes, Capsicum is a necessary. for now I just don't know how to get around it. I just think on pci_nvme_init, we get the SMART info from real device. and return that info when guest query SMART. so it will not update all the time. This way, guest application that depended on SMART Info will benefit from this fix. On Sat, Mar 21, 2020 at 9:49 AM John-Mark Gurney wrote: > > Wanpeng Qian wrote this message on Thu, Mar 19, 2020 at 12:09 +0900: > > > Can't you do what something like pci_passthru.c does in passthru_init, > > > and open /dev/nvme0 in pci_nvme_init? > > > > Yes, you are correct. but that will make /dev/nvme0 keep open all the time. > > I just thinking when guest fire a logpage command, open the /dev/nvme0 > > and get the SMART info. then close /dev/nvme0. > > But as you point out, the only way to have that happen is to remove > capsicum, but that would make byhve overall LESS secure. > > Even if you were able to open /dev/nvme0 at any time after the process > was locked down, it doesn't provide additional security, as any > attacker could just open it up, and do the operation... > > So, I'm really confused as to what the benefit of not opening it at > the start is.. > > > On Thu, Mar 19, 2020 at 2:59 AM John-Mark Gurney wrote: > > > > > > Wanpeng Qian wrote this message on Wed, Mar 18, 2020 at 13:05 +0900: > > > > But currently bhyve has Capsicum capability, I cannot > > > > open /dev/nvme0 within pci_nvme.c without extra code. > > > > (currently I just disable the Capsicum capability) > > > > > > > > any feedback? > > > > > > Can't you do what something like pci_passthru.c does in passthru_init, > > > and open /dev/nvme0 in pci_nvme_init? > > > > > > Or am I missing something? > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve: passthrough SMART info from host nvme controller
Wanpeng Qian wrote this message on Thu, Mar 19, 2020 at 12:09 +0900: > > Can't you do what something like pci_passthru.c does in passthru_init, > > and open /dev/nvme0 in pci_nvme_init? > > Yes, you are correct. but that will make /dev/nvme0 keep open all the time. > I just thinking when guest fire a logpage command, open the /dev/nvme0 > and get the SMART info. then close /dev/nvme0. But as you point out, the only way to have that happen is to remove capsicum, but that would make byhve overall LESS secure. Even if you were able to open /dev/nvme0 at any time after the process was locked down, it doesn't provide additional security, as any attacker could just open it up, and do the operation... So, I'm really confused as to what the benefit of not opening it at the start is.. > On Thu, Mar 19, 2020 at 2:59 AM John-Mark Gurney wrote: > > > > Wanpeng Qian wrote this message on Wed, Mar 18, 2020 at 13:05 +0900: > > > But currently bhyve has Capsicum capability, I cannot > > > open /dev/nvme0 within pci_nvme.c without extra code. > > > (currently I just disable the Capsicum capability) > > > > > > any feedback? > > > > Can't you do what something like pci_passthru.c does in passthru_init, > > and open /dev/nvme0 in pci_nvme_init? > > > > Or am I missing something? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve: passthrough SMART info from host nvme controller
I dont think that is insecure. as bhyve can passthrough real device to VM. as your point, that make more insecure, right? Such configuration will not enable by default. if user intend to do it, system has this ability instead of not implement. Simple is best, less is secure. I know that. but real world has all kinds of requirements. if you provide more, more people using it. On Thu, Mar 19, 2020 at 12:58 PM Jason Tubnor wrote: > > > > On Thu, 19 Mar 2020 at 14:09, Wanpeng Qian wrote: >> >> > Can't you do what something like pci_passthru.c does in passthru_init, >> > and open /dev/nvme0 in pci_nvme_init? >> >> Yes, you are correct. but that will make /dev/nvme0 keep open all the time. >> I just thinking when guest fire a logpage command, open the /dev/nvme0 >> and get the SMART info. then close /dev/nvme0. > > > So are you implying that it is safe for a guest to send such a call at > anytime? For those that use bhyve for isolation, this sort of facility would > be problematic not to mention insecure. ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve: passthrough SMART info from host nvme controller
On Thu, 19 Mar 2020 at 14:09, Wanpeng Qian wrote: > > Can't you do what something like pci_passthru.c does in passthru_init, > > and open /dev/nvme0 in pci_nvme_init? > > Yes, you are correct. but that will make /dev/nvme0 keep open all the time. > I just thinking when guest fire a logpage command, open the /dev/nvme0 > and get the SMART info. then close /dev/nvme0. So are you implying that it is safe for a guest to send such a call at anytime? For those that use bhyve for isolation, this sort of facility would be problematic not to mention insecure. ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve: passthrough SMART info from host nvme controller
> Can't you do what something like pci_passthru.c does in passthru_init, > and open /dev/nvme0 in pci_nvme_init? Yes, you are correct. but that will make /dev/nvme0 keep open all the time. I just thinking when guest fire a logpage command, open the /dev/nvme0 and get the SMART info. then close /dev/nvme0. On Thu, Mar 19, 2020 at 2:59 AM John-Mark Gurney wrote: > > Wanpeng Qian wrote this message on Wed, Mar 18, 2020 at 13:05 +0900: > > But currently bhyve has Capsicum capability, I cannot > > open /dev/nvme0 within pci_nvme.c without extra code. > > (currently I just disable the Capsicum capability) > > > > any feedback? > > Can't you do what something like pci_passthru.c does in passthru_init, > and open /dev/nvme0 in pci_nvme_init? > > Or am I missing something? > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve: passthrough SMART info from host nvme controller
Wanpeng Qian wrote this message on Wed, Mar 18, 2020 at 13:05 +0900: > But currently bhyve has Capsicum capability, I cannot > open /dev/nvme0 within pci_nvme.c without extra code. > (currently I just disable the Capsicum capability) > > any feedback? Can't you do what something like pci_passthru.c does in passthru_init, and open /dev/nvme0 in pci_nvme_init? Or am I missing something? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve: passthrough SMART info from host nvme controller
Hi Robert > I don't see why the guest needs to know about an implementation detail of the > host hardware. > If the host hardware is failing, that's something to be fixed on the host. > The guest should never realize that something was broken. I totally agree with you in this opinion. except one time when I am running a NAS virtual machine. providing two nvme disks for cache purpose. the NAS server cannot use them at first. currently the SMART data structure is all zero. so following two field of are zero when present to VM.. Available spare: 0 Available spare threshold: 0 The NAS server is thinking the disks are falling and suggest replacing them. I have to patch bhyve, providing some fake data. And I am thinking if we can provide the real hardware SMART to virtual machine, may be the virtual machine can monitor that information and send alert when hardware is falling. instead of the using smartmontools in FreeBSD host. And that is your decision whether you passthrough this information or not. the system just provide this ability. BR. Qian On Wed, Mar 18, 2020 at 9:57 PM Robert Crowston wrote: > > I don't see why the guest needs to know about an implementation detail of the > host hardware. > > If the host hardware is failing, that's something to be fixed on the host. > The guest should never realize that something was broken. > > Just my opinion. > > > ‐‐‐ Original Message ‐‐‐ > On Wednesday, 18 March 2020 04:05, Wanpeng Qian wrote: > > > Hello all. > > > > I have an idea about provide SMART of nvme controller. > > > > Currently bhyve's nvme controller didn't provide any SMART information. > > if we provide fake SMART, that is meaningless. > > > > I am thinking we can read the host nvme controller SMART and provide > > that to guest. > > > > such as > > > > nvme,disk1.img,maxq=16,qsz=8,ioslots=1,sectsz=512,ser=QNVME778,smart=nvme0 > > > > I have done some draft code. and it work. > > here is the output of nvmecontrol identify and logpage. > > > > root@smart:~ # nvmecontrol identify nvme0 > > Controller Capabilities/Features > > > > > > > > Vendor ID: fb5d > > Subsystem Vendor ID: > > Serial Number: QNVME778 > > Model Number: bhyve-NVMe > > Firmware Version: 1.0 > > Recommended Arb Burst: 4 > > IEEE OUI Identifier: 58 9c fc > > Multi-Path I/O Capabilities: Not Supported > > Max Data Transfer Size: 2097152 bytes > > Controller ID: 0x > > Version: 1.3.0 > > > > Admin Command Set Attributes > > > > > > > > Security Send/Receive: Not Supported > > Format NVM: Supported > > Firmware Activate/Download: Not Supported > > Namespace Managment: Not Supported > > Device Self-test: Not Supported > > Directives: Not Supported > > NVMe-MI Send/Receive: Not Supported > > Virtualization Management: Not Supported > > Doorbell Buffer Config: Not Supported > > Get LBA Status: Not Supported > > Sanitize: Not Supported > > Abort Command Limit: 3 > > Async Event Request Limit: 5 > > Number of Firmware Slots: N/A > > Firmware Slot 1 Read-Only: N/A > > Per-Namespace SMART Log: No > > Error Log Page Entries: 1 > > Number of Power States: 2 > > Total NVM Capacity: 0 bytes > > Unallocated NVM Capacity: 0 bytes > > > > NVM Command Set Attributes > > > > == > > > > Submission Queue Entry Size > > Max: 64 > > Min: 64 > > Completion Queue Entry Size > > Max: 16 > > Min: 16 > > Number of Namespaces: 1 > > Compare Command: Not Supported > > Write Uncorrectable Command: Not Supported > > Dataset Management Command: Not Supported > >
Re: bhyve: passthrough SMART info from host nvme controller
I don't see why the guest needs to know about an implementation detail of the host hardware. If the host hardware is failing, that's something to be fixed on the host. The guest should never realize that something was broken. Just my opinion. ‐‐‐ Original Message ‐‐‐ On Wednesday, 18 March 2020 04:05, Wanpeng Qian wrote: > Hello all. > > I have an idea about provide SMART of nvme controller. > > Currently bhyve's nvme controller didn't provide any SMART information. > if we provide fake SMART, that is meaningless. > > I am thinking we can read the host nvme controller SMART and provide > that to guest. > > such as > > nvme,disk1.img,maxq=16,qsz=8,ioslots=1,sectsz=512,ser=QNVME778,smart=nvme0 > > I have done some draft code. and it work. > here is the output of nvmecontrol identify and logpage. > > root@smart:~ # nvmecontrol identify nvme0 > Controller Capabilities/Features > > > > Vendor ID: fb5d > Subsystem Vendor ID: > Serial Number: QNVME778 > Model Number: bhyve-NVMe > Firmware Version: 1.0 > Recommended Arb Burst: 4 > IEEE OUI Identifier: 58 9c fc > Multi-Path I/O Capabilities: Not Supported > Max Data Transfer Size: 2097152 bytes > Controller ID: 0x > Version: 1.3.0 > > Admin Command Set Attributes > > > > Security Send/Receive: Not Supported > Format NVM: Supported > Firmware Activate/Download: Not Supported > Namespace Managment: Not Supported > Device Self-test: Not Supported > Directives: Not Supported > NVMe-MI Send/Receive: Not Supported > Virtualization Management: Not Supported > Doorbell Buffer Config: Not Supported > Get LBA Status: Not Supported > Sanitize: Not Supported > Abort Command Limit: 3 > Async Event Request Limit: 5 > Number of Firmware Slots: N/A > Firmware Slot 1 Read-Only: N/A > Per-Namespace SMART Log: No > Error Log Page Entries: 1 > Number of Power States: 2 > Total NVM Capacity: 0 bytes > Unallocated NVM Capacity: 0 bytes > > NVM Command Set Attributes > > == > > Submission Queue Entry Size > Max: 64 > Min: 64 > Completion Queue Entry Size > Max: 16 > Min: 16 > Number of Namespaces: 1 > Compare Command: Not Supported > Write Uncorrectable Command: Not Supported > Dataset Management Command: Not Supported > Write Zeroes Command: Not Supported > Save Features: Not Supported > Reservations: Not Supported > Timestamp feature: Not Supported > Verify feature: Not Supported > Fused Operation Support: Not Supported > Format NVM Attributes: All-NVM Erase, All-NVM Format > Volatile Write Cache: Not Present > > NVM Subsystem Name: > root@smart:~ # nvmecontrol logpage -p 2 nvme0 > SMART/Health Information Log > > == > > Critical Warning State: 0x00 > Available spare: 0 > Temperature: 0 > Device reliability: 0 > Read only: 0 > Volatile memory backup: 0 > Temperature: 309 K, 35.85 C, 96.53 F > Available spare: 100 > Available spare threshold: 10 > Percentage used: 0 > Data units (512,000 byte) read:
bhyve: passthrough SMART info from host nvme controller
Hello all. I have an idea about provide SMART of nvme controller. Currently bhyve's nvme controller didn't provide any SMART information. if we provide fake SMART, that is meaningless. I am thinking we can read the host nvme controller SMART and provide that to guest. such as nvme,disk1.img,maxq=16,qsz=8,ioslots=1,sectsz=512,ser=QNVME778,smart=nvme0 I have done some draft code. and it work. here is the output of nvmecontrol identify and logpage. root@smart:~ # nvmecontrol identify nvme0 Controller Capabilities/Features Vendor ID: fb5d Subsystem Vendor ID: Serial Number: QNVME778 Model Number:bhyve-NVMe Firmware Version:1.0 Recommended Arb Burst: 4 IEEE OUI Identifier: 58 9c fc Multi-Path I/O Capabilities: Not Supported Max Data Transfer Size: 2097152 bytes Controller ID: 0x Version: 1.3.0 Admin Command Set Attributes Security Send/Receive: Not Supported Format NVM: Supported Firmware Activate/Download: Not Supported Namespace Managment: Not Supported Device Self-test:Not Supported Directives: Not Supported NVMe-MI Send/Receive:Not Supported Virtualization Management: Not Supported Doorbell Buffer Config: Not Supported Get LBA Status: Not Supported Sanitize:Not Supported Abort Command Limit: 3 Async Event Request Limit: 5 Number of Firmware Slots:N/A Firmware Slot 1 Read-Only: N/A Per-Namespace SMART Log: No Error Log Page Entries: 1 Number of Power States: 2 Total NVM Capacity: 0 bytes Unallocated NVM Capacity:0 bytes NVM Command Set Attributes == Submission Queue Entry Size Max: 64 Min: 64 Completion Queue Entry Size Max: 16 Min: 16 Number of Namespaces:1 Compare Command: Not Supported Write Uncorrectable Command: Not Supported Dataset Management Command: Not Supported Write Zeroes Command:Not Supported Save Features: Not Supported Reservations:Not Supported Timestamp feature: Not Supported Verify feature: Not Supported Fused Operation Support: Not Supported Format NVM Attributes: All-NVM Erase, All-NVM Format Volatile Write Cache:Not Present NVM Subsystem Name: root@smart:~ # nvmecontrol logpage -p 2 nvme0 SMART/Health Information Log Critical Warning State: 0x00 Available spare: 0 Temperature: 0 Device reliability:0 Read only: 0 Volatile memory backup:0 Temperature:309 K, 35.85 C, 96.53 F Available spare:100 Available spare threshold: 10 Percentage used:0 Data units (512,000 byte) read: 173065 Data units written: 9381970 Host read commands: 4123220 Host write commands:846568092 Controller busy time (minutes): 948 Power cycles: 918 Power on hours: 2631 Unsafe shutdowns: 812 Media errors: 0 No. error info log entries: 2546 Warning Temp Composite Time:75 Error Temp Composite Time: 58 Temperature 1 Transition Count: 0 Temperature 2 Transition Count: 0 Total Time For Temperature 1: 0 Total Time For Temperature 2: 0 But currently bhyve has Capsicum capability, I cannot open /dev/nvme0 within pci_nvme.c without extra code. (currently I just disable the Capsicum capability) any feedback? ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
