want validation for Oxide serial numbers in the control plane

[hawkw]

For purposes like inventory and fault management, the control plane must often deal in Oxide serial numbers. Presently, we just represent these as Strings in Rust (or TEXT in CRDB) pretty pervasively. In many cases, it would be nice to have a representation for parsed and validated serials.

The primary motivation for this is stuff like what @smklein mentions in #8739 (comment) --- when writing ereports in a support bundle, we would like to include serial numbers in a filesystem path, and should therefore be able to ensure that serials received from the outside world don't contain unsavoury characters.

Another motivation, though, is that both the V1 and V2 Oxide serial formats described in RFD 219 are of fixed length and contain only ASCII characters. Thus, we ought to be able to store them as fixed-size arrays of 11 bytes, rather than UTF-8 Strings on the heap, which might be a bit more efficient when copying serials around.

Hubris has an oxide-barcode crate for this purpose, which includes parsing code. Perhaps we could depend on the parsing logic from there, or steal code from it.

[davepacheco]

We might consider where and whether it's useful to be able to store serial numbers that don't conform to our expectations. I think that was one of the motivations for using a String here. For example, can legit hardware be plugged in that would have a serial number that we don't recognize (because the software is old), or could we reasonably expect it to be misbehaving? What about use of these values on non-Oxide systems (e.g., PCs, simulation)?

[hawkw]

@davepacheco

We might consider where and whether it's useful to be able to store serial numbers that don't conform to our expectations. I think that was one of the motivations for using a String here.

So, hm. I feel somewhat complicatedly about this --- I agree that it's probably better for us to be able to represent serials/part numbers that are malformed or otherwise weird, given that in most cases, the control plane doesn't really care if they follow the formats described in RFD 219 and RFD 308. Perhaps just continuing to treat them as strings is the move, and we should just do some additional validation at the sites where we try to use them as filesystem paths etc.

However, I think most of the cases where we might encounter weird serials are not very likely:

For example, can legit hardware be plugged in that would have a serial number that we don't recognize (because the software is old)

There are two versions of the serial format described in RFD 219 , but these versions are self-describing: the V1 serial always begins with an alphabetic character, while the V2 serial always begins with the character 2. So a parser for these formats would be capable of handling both versions.

or could we reasonably expect it to be misbehaving?

This is certainly a potential concern if the VPD EEPROM is corrupted somehow. However, the SP's VPD code already validates some properties of serial/part number strings, and won't report them to the control plane if they don't meet those properties. So if we restrict ourselves to checking only the same constraints as the SP does, we can reasonably expect it to just not report serials that are sufficiently garbled to not match its own validation.

However, the SP's current validation is insufficient for some of the concerns I had here. In particular, it's not going to ensure that the characters in the serial are safe for use in a filesystem path. So, that doesn't really help us.

What about use of these values on non-Oxide systems (e.g., PCs, simulation)?

I am pretty sure that the only times we'd see serials/part numbers on non-oxide systems is when they're coming from a TOML config file or hard-coded in a test, so I'm not too worried about either of those. In the TOML config case, we could just make the configs do the same validation as the control plane when deserializing.

---

With all of this said, I think I'm going to punt on this for now, and solve the immediate problem by just doing the "is this safe for use in a FS path?" checking in #8739 at the site where we actually use them to construct paths. I did spend some time this morning putting together a little crate that does the parsing/validation of serials/part numbers/barcode strings, but I'm not totally convinced it's a good idea, and would rather pursue that separately from #8739.

[rmustacc]

So, hm. I feel somewhat complicatedly about this --- I agree that it's probably better for us to be able to represent serials/part numbers that are malformed or otherwise weird, given that in most cases, the control plane doesn't really care if they follow the formats described in RFD 219 and RFD 308. Perhaps just continuing to treat them as strings is the move, and we should just do some additional validation at the sites where we try to use them as filesystem paths etc.

Yes, I think we should be minimizing the amount of logic that we have here. For example, most folks assumed that the barcode format which was : delineated implied anything about the serial number length. And while there are going to be upper bounds, I don't think we should be doing additional validation at these layers in the stack.

Also, if you want to write things out by serial number today, is that going to remain true for all things? There are serial numbers that Oxide doesn't generate and while most are defined as ASCII, they are definitely just bytes in an eeprom and in the face of programming errors or related we can't assume they'll be UTF-8 safe (e.g. transceivers, disks, DIMMs, etc.).

The other problem here is that the stricter we are, the harder it is to roll out new versions of these things into the wild so I think the question I would have is something doesn't conform, what do we do? Reject it from joining the cluster? Disallow a field replacement, etc. The answer to some of these may be yes, but I think the motivation should be for this rather than a file system path.