On Wed, 2019-01-23 at 09:45 -0800, Dan Williams wrote: > >
[..] > On Thu, Jan 17, 2019 at 6:38 PM Dave Jiang <[email protected]> wrote: > > +static int store_kek(const char *provider, const char *kek) > > +{ > > + char path[PATH_MAX]; > > + FILE *fp; > > + ssize_t rc, wrote = 0; > > + int size = strlen(kek); > > + > > + rc = sprintf(path, "%s/%s.kek", NDCTL_KEYS_DIR, provider); > > + if (rc < 0) { > > + perror("sprintf kek path failed"); > > + return rc; > > + } > > + > > + fp = fopen(path, "w+"); > > + if (!fp) { > > + fprintf(stderr, "Opening file %s failed: %s\n", > > + path, strerror(errno)); > > + return -errno; > > + } > > + > > + do { > > + rc = fwrite(kek + wrote, 1, size - wrote, fp); > > + if (rc < 0) { > > + fprintf(stderr, "writing file %s failed: %s\n", > > + path, strerror(errno)); > > + fclose(fp); > > + return -errno; > > + } > > + wrote += rc; > > + } while (wrote != size); > > + > > + fclose(fp); > > + printf("key handle %s installed to %s\n", kek, path); > > + return 0; > > So the format of this file is just name it by the bus provider and > store the flat key name inside? That would seem to make supporting a > key per-dimm more complicated in the future. > > It would be nice to steal the git config file handling since it could > do something like this: > > [ key "<description>" ] > bus = <provider> > dimm = <dimm unique-id> > file = <path to key data> > > Where multiple keys can be recorded by unique descriptions and the > properties can be used as a match spec to scope that key to a set of > DIMMs. For example a system-wide master key > > [ key "system-master" ] > bus = all > file = key.blob > > ...and the following would identify a kek for a single dimm. > > [ key "dimm0" ] > dimm = "8680-57341200" > file = key.blob > > ...the roadblock of course being how easy (or not easy) it is to steal > the config file capabilities from git. > > Too complicated? Other ideas? I like the general scheme.. But it sounds like a pre-requisite for this might be the config rework that we will have for ndctl-monitor in the future. I'm trying to think of how this will tie in with that - ideally we have one global config file, and that includes sections for different commands. Ideally keys also get described there.. Maybe each [key "foo"] section can be such a top level section? The other option is a security specific config file, but if we're unifying the config file handling, I think this should be part of it from the start. _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
