Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-07-02
19:31:58 dansmith it's an implementation detail
19:32:14 dansmith if the thing (which the user can't see) supports it, it works, and if not it's 501
19:32:40 mriedem or 400 if i just return None
19:32:41 dansmith they can't see that libvirt didn't support it before, got a 501, and that either now it does support it, or some other driver is being used
19:33:03 mriedem in this case the user == admin anyway,
19:33:08 mriedem so another reason why it's a minor concern for me
19:33:37 dansmith right, but this is not necessarily an admin user that has visibility into the hypervisor details
19:34:03 dansmith this could be a level-1 lab monkey that needs to disable a host to go blow dust out of the fans or something
19:34:51 dansmith anyway, just saying I don't think we should tie behavior of a microversion to a version of the implementation underneath when the behavior and semantics haven't changed
19:35:11 mriedem sure. if you don't think anything needs to change that's fine with me. would appreciate a comment in the review for if/when someone comes along saying it's a change.
19:35:19 mriedem also note the api ref is pretty clear to not use that api https://developer.openstack.org/api-ref/compute/?expanded=update-host-status-detail#update-host-status
19:35:19 dansmith will
19:46:37 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Remove unreachable native QEMU iSCSI initiator config code https://review.opendev.org/668750
20:07:06 openstackgerrit Matt Riedemann proposed openstack/nova master: Add placement request pre-filter compute_status_filter https://review.opendev.org/668752
20:42:12 openstackgerrit Matt Riedemann proposed openstack/nova master: Refactor HostAPI.service_update https://review.opendev.org/668756
20:50:31 melwitt efried, jroll, dansmith: fwiw, an idea we had when I chatted with penick about the TPM thing was tracking the "TPM availability" outside of placement using a scheduler filter and a new compute stat. the compute stat would be something like 'tpm_project_id' and defaults to None. and the scheduler filter passes a host only if 'tpm_project_id' is None or matches project_id [if a tpm is requested]. and then in nova-compute, set
20:50:31 melwitt 'tpm_project_id' compute stat to the project_id when a tpm request lands on the host. and the 'tpm_project_id' stat gets cleared during init_host
20:51:53 efried melwitt: Except for that last bit. Having restarted the compute service does *not* mean the TPM is clear and ready for use by someone else. The only way we can know that bit is if the admin tells us so.
20:52:04 melwitt the only caveat I was thinking here is that init_host doesn't guarantee a reboot happened
20:52:13 efried just so
20:52:24 melwitt yeah
20:52:24 efried and a reboot doesn't guarantee the TPM was cleared.
20:52:43 melwitt oh, ok, I didn't know that or misunderstood
20:52:58 sean-k-mooney is there any reason we cant wipe the tpm directly when we delete a vm that is using it
20:53:05 efried a reboot is required, but not sufficient. You had to have done some kind of purgey command prior
20:53:13 melwitt sean-k-mooney: from what penick said, that is not possible
20:53:22 melwitt efried: I see
20:53:41 sean-k-mooney efried: is a reboot requried or can we do a device reset
20:53:57 sean-k-mooney i have not looked into it but i know fo bios based gpus a reboot was required
20:54:06 efried I don't know whether "purgey command" is "device reset" or what, but you have to reboot the host for it to be reusable.
20:54:07 sean-k-mooney for uefi based gpus a deivce reset was enough
20:54:28 sean-k-mooney it could depend on the type of tpm you have
20:54:40 sean-k-mooney there are several diffeerent tpm types
20:54:50 efried how would we know?
20:54:50 sean-k-mooney that are connect over different buses
20:56:05 mriedem sure sounds like hardware management that nova shouldn't be doing...
20:56:06 sean-k-mooney im not sure https://en.wikipedia.org/wiki/Trusted_Platform_Module#TPM_implementations
20:57:03 sean-k-mooney i think descret tp0ms and maybe the integrated tpm in the intel chips set can be passthed through
20:57:15 sean-k-mooney the firware and software one obviosly cant be
20:57:45 efried mriedem, melwitt: in case y'all weren't silently following along, here's the earlier conversation with jroll and dansmith: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-07-02.log.html#t2019-07-02T17:30:56
20:57:54 mriedem efried: i saw it
20:58:04 mriedem and agreed with the -5 comment
20:58:09 efried k
20:58:10 melwitt efried: yeah, I mentioned what I did bc I read it
20:58:16 efried k
20:58:36 efried thanks for the followup
20:58:37 melwitt at the very least for any potential downstream-only endeavor
20:59:46 sean-k-mooney i takeign booting windows to run the clear-tpm powershell commadn is not a thing we cand do :) https://docs.microsoft.com/en-us/powershell/module/trustedplatformmodule/clear-tpm?view=win10-ps
21:00:03 sean-k-mooney its rare that all the hits i get in google are for windows
21:00:26 melwitt if there were a way we could query the tpm device to know whether it's clear/ready, then IMO it seems similar enough to pci passthrough and not so bad
21:00:58 melwitt but since there's not, then I agree it doesn't fit
21:01:41 sean-k-mooney apparent there is a tpm_clear command
21:01:58 mriedem we have also done a poor job at times of tracking allocated pci devices
21:02:07 sean-k-mooney just reading https://resources.infosecinstitute.com/linux-tpm-encryption-initializing-and-using-the-tpm/#gref
21:02:10 openstackgerrit Merged openstack/nova stable/rocky: libvirt: Rework 'EBUSY' (SIGKILL) error handling code path https://review.opendev.org/667436
21:02:35 mriedem e.g. https://review.opendev.org/#/q/I6e871311a0fa10beaf601ca6912b4a33ba4094e0
21:02:52 melwitt aye
21:03:33 sean-k-mooney it looks like clearing the tpm makes it unowned and disablses it which requries a reboot to fix
21:03:57 melwitt yeah, that's what efried was saying earlier. it's a two-step deal
21:06:04 sean-k-mooney ya diging a bit deeper it looks like linux cant actully clear teh tpm its self for security reason and its actully the uefi on reboot that is clearing it
21:06:25 sean-k-mooney so ya based on that i think this is a non starter
21:07:03 sean-k-mooney we we need to do is impove qemu to make vTPM more secure by not storign the encryption key on the host
21:07:19 sean-k-mooney perhaps by storign it in the host tpm
21:07:35 sean-k-mooney or barbacan or some other keystore
21:08:27 melwitt yeah, qemu enhancement is needed. I'm not sure if that's on their radar already. could ask kashyap maybe
21:09:39 efried it is
21:10:01 efried just not going to be ready in time for T
21:10:22 melwitt ah ok
21:31:55 sean-k-mooney efried: gibi so have we talked about how we handel move operations for the encryped image spec https://review.opendev.org/#/c/608696/8/specs/train/approved/image-encryption.rst@285
21:32:51 sean-k-mooney i would be in faovr of supporting this as an experimenal feature without them but im hopping at least cold migraiton and live migration might work
21:33:07 sean-k-mooney rescue,shelve and cross cell resize might be tricker
21:33:25 sean-k-mooney if we have snapshot working it shoudl be possibel to support them however
21:33:41 efried sean-k-mooney: I wouldn't expect this to affect lifecycle operations
21:34:11 efried because the change is in the image processing layer
21:34:27 sean-k-mooney well for rescuse we are temporaily booting the instance with a different image but we still need to be able to decypt its disks
21:34:52 efried The disk is not encrypted at that point.
21:35:04 efried this isn't like LUKSing the boot disk.
21:35:06 sean-k-mooney and for shelve/cross cell resize we need to ensure we create encrypted snapshots for encrypted instances
21:35:24 efried This is encrypting it in glance. It gets decrypted when it's copied into the instance's storage.
21:35:39 sean-k-mooney the instaces storage is also encrypted
21:35:49 sean-k-mooney its not stored decyped on the compute node
21:35:56 efried um
21:36:03 efried then I wildly misunderstood the spec
21:36:39 sean-k-mooney "Using encrypted storage backends for volume and compute hosts in conjunction
21:36:41 sean-k-mooney with direct data transfer from/to encrypted images can enable workflows that
21:36:43 sean-k-mooney never expose an image's data on a host's filesystem.
21:36:45 sean-k-mooney "
21:37:01 efried right, but "using encrypted storage backends" is not part of this spec
21:37:06 efried that's already supported
21:38:29 sean-k-mooney right but that means on the host the iamge is still encrypted as its streamed into an encpted file
21:39:12 sean-k-mooney so when you do a nova rescue and you boot form a different image you still need to pass the encyption key to qemu so it can open that encypted file a use it
21:39:26 efried Not "still encrypted". decrypted to clear, then re-encrypted with a different key (and possibly a different algorithm, etc)
21:40:09 efried so yes, *if* your storage backend is encrypted, regardless of whether you're using *image* encryption (this feature), then you'll need to manage slinging keys around.
21:40:15 sean-k-mooney the decypted to clear happens in memory. but when i was referign to still encrypted i ment after it was re encrypted
21:40:31 efried I'm saying they're separate and unrelated.
21:40:33 sean-k-mooney ok so long as that all works that is cool
21:40:39 efried I think
21:40:50 sean-k-mooney i just was suprised that it was never mention in the spec
21:43:44 sean-k-mooney i could cahcne my +1 to a -1 i guess until josephine seifert replies to confirm but i whould have expect this to at least be mentioned in the spec if all it was is "it jsut works"
22:12:27 mriedem dansmith: you know how this set_host_enabled is a blocking rpc call? if this is an ironic compute service managing 1000 compute nodes (1000 resource providers) and we have to sync the trait on all of them, i'm not sure if that would take more than 60 seconds but it might - thinking this change should use the long_rpc_timeout for that call now - agree?

Earlier   Later