Re: sysfs binary attribute API flux

[Jonathan McCune]

On Thu, Mar 22, 2012 at 5:28 PM, Greg KH <greg@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/