| opendevreview | chandan kumar proposed openstack/cyborg-specs master: Add generic NVMe driver spec with secure cleanup https://review.opendev.org/c/openstack/cyborg-specs/+/985349 | 06:09 |
|---|---|---|
| chandankumar | sean-k-mooney: Hello | 09:44 |
| sean-k-mooney | o/ | 09:44 |
| chandankumar | I wanted to discuss about nvme cleanup fallback strategy. | 09:44 |
| chandankumar | In previous draft spec, we were checking whether the driver supports which of the cleaning strategy: nvme sanitize (CES, BES, OWS) or nvme format(SES2, SES1). If not then we can move it shred or dd. But shred or dd is not gurantee secure erase. | 09:44 |
| chandankumar | Since In libvirt emuluted nvme, it supports SES2 and SES1. SES2 performs cypto erase | 09:44 |
| chandankumar | It is the last cleaning strategy available for testing right now in our emulated env. | 09:44 |
| sean-k-mooney | secure erase is not the goal | 09:45 |
| chandankumar | Here is what I was thinking about new cleanup strategy: | 09:45 |
| sean-k-mooney | cleaning is | 09:45 |
| chandankumar | nvme sanitize (CES, BES, OWS) then nvme format(SES2) if not supported then move the device to error state and let' operator decide what to do that. | 09:45 |
| sean-k-mooney | no | 09:45 |
| sean-k-mooney | either we only suprpot device with sanitize | 09:45 |
| sean-k-mooney | or we have a fallback that works for all devices | 09:46 |
| sean-k-mooney | but its not ok for use to provision a device to a vm that we cant clean | 09:46 |
| sean-k-mooney | we coudl use nvme format | 09:46 |
| sean-k-mooney | but if the device will alwasy end up in error then we shoudl not allow ti to be managed by cybrog | 09:46 |
| sean-k-mooney | also while we can have teird cleaning levels we should not fallback at runtime | 09:47 |
| sean-k-mooney | we shoudl discover the clenaing supprot level and or allow specify the cleaning mode via the config but we shoudl only attpemt one method of cleaning in the runtime path | 09:48 |
| sean-k-mooney | shread/dd woudl jusut overrite the entirly block device if we use that path | 09:49 |
| sean-k-mooney | that is what we do for lvm volumes in cidner and nova | 09:49 |
| chandankumar | Not all devices support nvme format also | 09:50 |
| sean-k-mooney | right which is why im not really that intersted in supproting that | 09:50 |
| sean-k-mooney | dd/sheread is a universal method that will work its just slow and consumes a full driver write cycle | 09:50 |
| chandankumar | in that case, we have two options 1. use fallback as shread or dd (just like nova or cinder) or 2. provide cleanup method via config | 09:51 |
| chandankumar | But if we pass the cleanup method via config, how os-triats will report to placement here | 09:51 |
| sean-k-mooney | we woudl filter the triat based on the selected cleanup method | 09:52 |
| chandankumar | if it might be something else other than snaitize or dd/shread | 09:52 |
| sean-k-mooney | it wont be arbaitary | 09:52 |
| sean-k-mooney | it would be and enuma of "sanitize", "format" or "zero" | 09:53 |
| sean-k-mooney | zero beign shread or dd | 09:53 |
| chandankumar | ok, in that case it will work | 09:53 |
| sean-k-mooney | i have no interest in allowing oeprator to pass a cleaning command | 09:54 |
| sean-k-mooney | that is a security nightmare so while i am ok with them chooing a policy | 09:55 |
| sean-k-mooney | im not ok with giving them free rain to plug in anything they want fro the cleaning command | 09:55 |
| sean-k-mooney | we can also supprot an auto value as the default | 09:55 |
| sean-k-mooney | where we will use the best/fasted method the device supprots | 09:56 |
| chandankumar | yes, that source better | 09:56 |
| sean-k-mooney | so the config option (in the device-spec) would not be required its just an overried if the operaotr need to set it for soem reason i.e. there device is buggy | 09:56 |
| chandankumar | so the cleanup option would be auto, santitize, format, zero | 09:57 |
| sean-k-mooney | yep i think that woudl work again we can decied if we want to suprpot format or not | 09:57 |
| sean-k-mooney | but that somethign we can refine at implemation time | 09:58 |
| chandankumar | perfect | 09:58 |
| sean-k-mooney | how common is it that sanatize is not supproted these days | 09:58 |
| sean-k-mooney | most read intensive ssd are rated at 1 total drive write per day DWPD wer as mixed use drives are rated at 10 adn write intensive deves at 25+ | 09:59 |
| sean-k-mooney | so on a moder driver just zeroing it with dd/shred is not terible for the lifetime of the drive | 10:00 |
| sean-k-mooney | and if your passing a drive to a vm they can do that anyway | 10:00 |
| sean-k-mooney | so i think having "zero" as the work for anything fallback is fine for legacy drives but i suspect almost everyting will work with on eof the sanitize levels | 10:01 |
| sean-k-mooney | we could also looks at blockdiscard/trim but we can dicuss that later when it comes to reiving the zero implemation | 10:03 |
| chandankumar | nvme sanitize was added nvme 1.3 specification, these days most of the nvme device comes with nvme 2.0 | 10:04 |
| chandankumar | it should have sanitize | 10:04 |
| sean-k-mooney | right that my thinkign as well | 10:04 |
| chandankumar | The I have in my laptop have , it does not support cyrpot erase | 10:05 |
| chandankumar | Block Erase Sanitize Operation Supported | 10:05 |
| sean-k-mooney | ya so again cyrpto erase is nice to have but not required | 10:06 |
| sean-k-mooney | if you want encypted storage you should just add luks on top of the nvme device in the gust | 10:07 |
| sean-k-mooney | an not rely on the device cleaning to do that for you | 10:07 |
| chandankumar | yes adding luks wuld do the job | 10:08 |
| chandankumar | let me update the spec based on above discussion | 10:08 |
| chandankumar | thank you! | 10:08 |
| sean-k-mooney | my intuition is to just supprot sanatize and zero by the way | 10:08 |
| sean-k-mooney | and skip format entirly | 10:08 |
| sean-k-mooney | i do not like that format only works on the first namespace | 10:09 |
| sean-k-mooney | or if a namespace still exists | 10:09 |
| chandankumar | sure, I will drop format | 10:10 |
| sean-k-mooney | cool any other question on any of the feedback i left on the spec? | 10:11 |
| sean-k-mooney | ill try and do anohter full pass over it in the next day or two | 10:11 |
| chandankumar | nope rest of them I have address | 10:11 |
| chandankumar | I will try to get it updated by eod or tomorrow morning | 10:11 |
| sean-k-mooney | cool ill plan to take a look tomorow or wednesday so | 10:12 |
| sean-k-mooney | assuming there are no other issues and we are mostly aligned we will probly merge it end ro week or early next week | 10:12 |
| chandankumar | sounds good | 10:18 |
| sean-k-mooney | so thinking about this i wonder if cypto erase need to be configurable. the block erase version of sanitize and format is actully more secure then cypto erase alone | 10:26 |
| sean-k-mooney | so we could consider 2 tuneable | 10:26 |
| sean-k-mooney | clear_mode=block|crypto clear_method=sanatize|zero | 10:27 |
| sean-k-mooney | clear_mode=block|crypto|auto clear_method=sanatize|zero|auto | 10:28 |
| sean-k-mooney | chandankumar: it really is 2 seperate question so i think that might be a better way to model it | 10:28 |
| sean-k-mooney | chandankumar: apprenly there is also a nvme write-zeroes command | 10:29 |
| sean-k-mooney | chandankumar: so we can use that instead of dd or shred for the zero fallback if supproted | 10:29 |
| chandankumar | yes, The Write Zeroes command is used to set a range of logical blocks to zero. | 10:30 |
| sean-k-mooney | yep but it can zeor the entire device and its doe by the cornoler rather then the cpu | 10:31 |
| sean-k-mooney | so in zero mode waht we could do is delete all namespace, create 1 namespace that cover the entire device and then zero it with write-zeors | 10:32 |
| sean-k-mooney | i also think we need to do that namespace reset in general | 10:32 |
| sean-k-mooney | so as part of cleaning we will need to ensure we have restored teh defivce to havign 1 namespace that uses the entire device | 10:32 |
| sean-k-mooney | in case the tenatn had reconfigured it to soemthing else | 10:33 |
| chandankumar | sudo nvme id-ctrl /dev/nvme0n1 -H | grep -A 10 "oncs" | 10:34 |
| chandankumar | oncs : 0xdf | 10:34 |
| chandankumar | [12:12] : 0 Namespace Zeroes Not Supported | 10:34 |
| chandankumar | [11:11] : 0 Maximum Write Zeroes with Deallocate Not Supported | 10:34 |
| chandankumar | [10:10] : 0 All Fast Copy Not Supported | 10:34 |
| chandankumar | [9:9] : 0 Copy Single Atomicity Not Supported | 10:34 |
| chandankumar | [8:8] : 0 Copy Not Supported | 10:34 |
| chandankumar | [7:7] : 0x1 Verify Supported | 10:34 |
| chandankumar | [6:6] : 0x1 Timestamp Supported | 10:34 |
| chandankumar | [5:5] : 0 Reservations Not Supported | 10:34 |
| chandankumar | [4:4] : 0x1 Save and Select Supported | 10:35 |
| chandankumar | [3:3] : 0x1 Write Zeroes Supported | 10:35 |
| chandankumar | Let me read about this one | 10:36 |
| chandankumar | current spec does not focus on namespace. | 10:42 |
| sean-k-mooney | right that a gap we need to adress | 10:43 |
| chandankumar | we need retrive all the namespace from the contoller, then delete all of them and create single namespace then perform nvme write zero | 10:43 |
| chandankumar | Do we need to do it in the same one? Do a follow up on that? | 10:43 |
| chandankumar | or just make a note, follow up during implementation | 10:44 |
| sean-k-mooney | this need to be done in this spec | 10:47 |
| sean-k-mooney | not as a followup | 10:47 |
| chandankumar | ok | 10:48 |
| sean-k-mooney | we need to ensure we provide the deivce in a standarized repoducabel state | 10:48 |
| sean-k-mooney | regardless of what the previous user did to it | 10:48 |
| sean-k-mooney | so 1 namespace for the entire device, cleared or previosu content and we shoudl likely also ensure that there are no encyption keys present but that might be somethign we can defer to the implemeation | 10:49 |
| chandankumar | for sanitize, we donot need to worry about namespace, for write zeros, we can pull the namespace, delete all ns and create one, perform write zero | 10:53 |
| chandankumar | one more question | 10:53 |
| chandankumar | regarding config option, clear_mode=block, clear_method=sanitize, you have used pipe to specify all the option here just for example | 10:55 |
| sean-k-mooney | yep that just me showitn the options of the enum | 10:55 |
| chandankumar | ok, got it | 10:55 |
| sean-k-mooney | so this is a summary of what iw was tahttign to you about with ai https://paste.opendev.org/show/bDKh5ZaFcfOv7lDGlLer/ | 10:56 |
| chandankumar | ah good, I did not thought about passing via device_spec | 10:58 |
| sean-k-mooney | i gave it your latest spec draft and asked it to codify the options we were discusion into a new section that you could include | 10:58 |
| sean-k-mooney | well we need to set this per device | 10:59 |
| sean-k-mooney | so that the simpler way to do that | 10:59 |
| chandankumar | yup, it is much simpler | 10:59 |
| sean-k-mooney | we may consider allowign this as a atibute via the api in the future | 10:59 |
| sean-k-mooney | but for now lets keep it simple | 10:59 |
| sean-k-mooney | https://paste.opendev.org/show/bDKh5ZaFcfOv7lDGlLer/ is not entirly correct in that cyborg wont do any driver binding | 11:00 |
| sean-k-mooney | that shoudl happen when the qemu isntance is stopped/deleted by libvirt automaticlly | 11:01 |
| sean-k-mooney | this is assuming managed=yes semantics | 11:01 |
| sean-k-mooney | so cyborg will assume that we can just use nvmcli witht hedefivce and we cna declare all device driver binding out of scope | 11:02 |
| sean-k-mooney | otherwise that sumamry is close to what i woudl write in the spec | 11:02 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!