Messages in this thread | | | Date | Fri, 23 Mar 2012 09:25:54 -0400 | Subject | Re: sysfs binary attribute API flux | From | Jonathan McCune <> |
| |
On Thu, Mar 22, 2012 at 5:28 PM, Greg KH <greg@kroah.com> wrote: >> necessary to move some binary data from userspace into the kernel. > What exact type of binary data are you talking about here?
There is a statically linked executable, which will also take a binary blob as input, and produce another as output.
>> have been using sysfs's 'struct bin_attribute'. Unfortunately, every >> few kernel versions, my code breaks because of a change in the >> definition of some elements in this struct. For example, kernel > > Is this a problem? It's only an issue for code that lives outside of > the kernel, and there's nothing we can do about that, sorry.
My main question is one about best practices. If using sysfs and keeping up with such changes is the best option available, I can live with that. However, if I've somehow missed a preferred alternative, then I would like to use it.
> debugfs?
This may be an option, but my understanding is that it makes even fewer promises about API stability.
> What exactly are you using this data for? Who creates it? What does it > represent?
The research project involves using Intel TXT (or the AMD SVM equivalent) as a form of context switch mechanism to execute the statically-linked binary code in isolation from the rest of the system. Thus, there's some amount of systems-level code (executes in ring 0) in the binary to preserve the state of the Linux kernel, but the majority of it performs some kind of application-specific (executes in ring 3) function (e.g., protects some SSL / SSH / VPN keys). Another way to think about it is as a provision for arbitrarily many virtual smart cards, e.g., from userspace this shouldn't look all that different from loading binary code into some kind of peripheral device with support for arbitrary execution. In case you're interested in the code or the research paper describing the approach in more detail:
http://flickertcb.sourceforge.net/
http://www.ece.cmu.edu/~jmmccune/papers/mccune_parno_perrig_reiter_isozaki_eurosys08.pdf
Many thanks for your time, -Jon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |