Winkler, Tomas <[email protected]> writes:
> Hi, yes the OASIS spec is based around this ACRN solution. We are still > planning on another Linux kernel submission effort, actually in the next > release cycle. > The capability message which is not implemented in the virtio solution is due > to NVMe support, which didn't make into OASIS spec. > There is an rpmb tool under tools/rpmb of the Linux kernel, also AOS guest on > ACRN uses this interface, there should be doc under > Documentation/driver-api/rpmb/. Thanks for the pointers they are really helpful. > I'm not sure how updated is ACRN public tree, but I'll post > https://github.com/tomasbw/linux-mei rpmb branch, I hope in a week or > two. Thanks. Looking at the ACRN tree when their base rpmb commit (01abd0e5) as added on a 5.4 based machine. The commits have V10 references bellow the --- which implies some changes from your series against v4.14-rc5. I've cherry-picked the initial ones out of the ACRN tree and they seemed to re-base onto v5.6.7 reasonably enough (untested branch): https://git.linaro.org/people/alex.bennee/linux.git/log/?h=review/rpmb There are a bunch more commits touching that in the ACRN tree but hopefully this will give me a minimum testing set without having everything else that's in there. It does make me wonder if any of these patches are on an upstream path or are they likely to live in 3rd party trees forever? > There is also a simulation HW drivers/char/rpmb/rpmb_sim.C it's based on eMMC > part of the spec. > I do have some very simple tests to exercise this interface. > > Thanks > Tomas > > > >> -----Original Message----- >> From: Alex Bennée <[email protected]> >> Sent: Friday, May 08, 2020 19:12 >> To: [email protected]; Winkler, Tomas >> <[email protected]>; Huang, Yang <[email protected]> >> Cc: Zhu, Bing <[email protected]>; Michael S.Tsirkin <[email protected]>; >> Ilias >> Apalodimas <[email protected]> >> Subject: VIRTIO RPMB Front End drivers for Linux >> >> >> Hi, >> >> I'm currently working on a vhost-user backend for virto-rpmb as defined in >> the >> draft version of the OASIS spec (since 8c6acac2). I'm developing it within >> the >> QEMU source tree but it is intended to be a portable vhost-user binary with >> minimal POSIX like dependencies. >> >> Part of the aim of the project is to experiment with a vhost-user backend >> that >> has minimal access to guest memory and RPMB makes sense as the vhost-user >> daemon only really needs to see the virt queues to pass the data back and >> forth. >> One eventual architecture would be to move the vhost-user driver into it's >> own >> isolated VM with only minimal memory sharing between the guest and it's back- >> end. >> >> I've gotten enough of the plumbing working now that I'm ready to start >> implementing the RPMB spec itself. I've been looking for a front-end to use >> in >> testing and I found the Linux driver sitting in Project ACRN's guest kernel >> fork. >> With this kernel and VIRTIO_ID_RPMB tweaked to the standard based one I get >> far enough that the driver is initialised before my drivers falls over when >> an un- >> handled feature is requested (0x130000000). This is slightly confusing >> because >> the spec doesn't define any feature bits. So a few questions: >> >> - how divergent is the virtio-rpmb front/back-end in ACRN from the >> OASIS spec? >> >> - is there likely to be another submission to the upstream kernel? >> >> I've also read the document on the ACRN website which talks about the secure >> architecture: >> >> https://projectacrn.github.io/latest/tutorials/trustyACRN.html >> >> I was wondering if there was any low level usage information. From looking at >> the Kconfig options it seems the virtio-rpmb driver interfaces with a wider >> RPMB >> sub-system which exposes a character device to the kernels user-space. So: >> >> - are there any special user-space tools to use this interface? >> >> - is there a write-up somewhere of how to exercise the interface or >> any sort of test suite? >> >> Thanks in advance, >> >> >> -- >> Alex Bennée -- Alex Bennée --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
