You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesatee.apache.org by Wang Pei <ur...@apache.org> on 2019/12/04 20:08:30 UTC
Support for coarse-grained code auditing
One of the features MesaTEE (now renamed as Teaclave) promised when it was
initially open-sourced is the so-called "Non-bypassable gateway."
Basically, we would like to show that all interactions between the TEE and
the untrusted outside world are properly sanitized in our implementation.
As a first step towards this goal, I have implemented a tool that can
extract the dependency graph of the crates built by Cargo. It's
instrumentation to rustc that analyzes the Rust IR and stores information
with an embedded DB such that it can gather information collected by
multiple rustc invocations.
The tool provides three custom attributes: require_audit, audited, and
entry_point. These attributes can annotate any item-like entities in Rust
code, including ADT, functions, traits, and impl blocks. Starting from each
entry_point, the tool traverses the dependency graph with DFS and emits a
warning whenever it encounters an item marked by require_audit unless
another item marked by audited presents along the traversal path.
The attributes have no effects on code generation and can be safely ignored
by anyone that does not care about code auditing.
About how to publish the tool, there are two options. It can be part of
mesatee-sgx, the fundamental dependency of the mesatee project. Or it can
be released as a standalone tool. In theory, it can be used to audit other
Rust projects, but I wonder how attractive that would be. Either way, we
have to annotate a lot of code in mesatee-sgx and mesatee to make the tool
acutally useful.
Let me know your thoughts.
Pei
Re: Support for coarse-grained code auditing
Posted by Matt Sicker <bo...@gmail.com>.
Essentially, as long as we can still perform a release on it if needed,
that’s the baseline. Say a security issue pops up or things like that.
Documentation for others to make a release will certainly help there, but I
think we probably need to do a release first before it can be effectively
documented.
On Wed, Dec 4, 2019 at 16:58 Wang Pei <ur...@gmail.com> wrote:
> Matt,
>
> Thanks for the thoughtful comments.
>
> There shouldn't be any problem with licensing. Regarding your other
> concerns, I have some more information. It's a very tiny tool (about 1300
> lines of Rust). It provides very limited functionality, and only works with
> a particular version of the Rust compiler (the exact version specified by
> Teaclave and its dependencies). In this sense, releasing it as a separate
> tool seems a bit overkill. Indeed, it's a bit isolated in terms of
> development since it's a rustc plugin rather than anything directly related
> to Teaclave. However, I don't think we will need to actively develop it as
> we do for the rest part of Teaclave. There is no plan to expand its
> functionality, although it does need maintenance because every time
> Teaclave updates its toolchain version the internal APIs of rustc change.
>
> With all that said, I do see a point in making the tool as a separate
> project. More discussions are welcome!
>
> Pei
>
> On Wed, Dec 4, 2019 at 1:46 PM Matt Sicker <bo...@gmail.com> wrote:
>
> > Whether you'd like to make this part of the project here or externally
> > really depends on a few things:
> >
> > * Licensing: if it's Apache licensed, then not an issue.
> > * Community: if it's a tool being developed by only one of the
> > committers, then it's fairly difficult for the rest of the community
> > to vote on releases for it.
> > * Releases: is it released on its own cycle from other repos? If so,
> > note what I mentioned about community which can cause releases to get
> > delayed waiting for enough votes.
> >
> > I suspect this component is appropriate to put here. Whether we'd like
> > it in its own git repo or not is another question.
> >
> > On Wed, 4 Dec 2019 at 14:08, Wang Pei <ur...@apache.org> wrote:
> > >
> > > One of the features MesaTEE (now renamed as Teaclave) promised when it
> > was
> > > initially open-sourced is the so-called "Non-bypassable gateway."
> > > Basically, we would like to show that all interactions between the TEE
> > and
> > > the untrusted outside world are properly sanitized in our
> implementation.
> > >
> > > As a first step towards this goal, I have implemented a tool that can
> > > extract the dependency graph of the crates built by Cargo. It's
> > > instrumentation to rustc that analyzes the Rust IR and stores
> information
> > > with an embedded DB such that it can gather information collected by
> > > multiple rustc invocations.
> > >
> > > The tool provides three custom attributes: require_audit, audited, and
> > > entry_point. These attributes can annotate any item-like entities in
> Rust
> > > code, including ADT, functions, traits, and impl blocks. Starting from
> > each
> > > entry_point, the tool traverses the dependency graph with DFS and
> emits a
> > > warning whenever it encounters an item marked by require_audit unless
> > > another item marked by audited presents along the traversal path.
> > >
> > > The attributes have no effects on code generation and can be safely
> > ignored
> > > by anyone that does not care about code auditing.
> > >
> > > About how to publish the tool, there are two options. It can be part of
> > > mesatee-sgx, the fundamental dependency of the mesatee project. Or it
> can
> > > be released as a standalone tool. In theory, it can be used to audit
> > other
> > > Rust projects, but I wonder how attractive that would be. Either way,
> we
> > > have to annotate a lot of code in mesatee-sgx and mesatee to make the
> > tool
> > > acutally useful.
> > >
> > > Let me know your thoughts.
> > >
> > > Pei
> >
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@mesatee.apache.org
> > For additional commands, e-mail: dev-help@mesatee.apache.org
> >
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: Support for coarse-grained code auditing
Posted by Wang Pei <ur...@apache.org>.
Let's decide how this should be handled after SDK 1.10 release.
On Wed, Dec 4, 2019 at 3:16 PM Matt Sicker <bo...@gmail.com> wrote:
> There are two things: having a separate git repo (or not), and having it
> part of the project or 3rd party. We can have multiple git repos on
> apache.org.
>
> On Wed, Dec 4, 2019 at 17:13 Mingshen Sun <bo...@mssun.me> wrote:
>
> > Pei, I think Matt’s point is on the situation if you want to separate
> this
> > project as an individual project.
> >
> > So, for this tool, I think the question is whether to put it in the
> > `apache/incubator-mesatee` repo or a new `apache/incubator-mesatee-xxx`
> > repo.
> >
> > Does this explanation clear to you?
> >
> > > On Dec 4, 2019, at 2:57 PM, Wang Pei <ur...@gmail.com> wrote:
> > >
> > > Matt,
> > >
> > > Thanks for the thoughtful comments.
> > >
> > > There shouldn't be any problem with licensing. Regarding your other
> > > concerns, I have some more information. It's a very tiny tool (about
> 1300
> > > lines of Rust). It provides very limited functionality, and only works
> > with
> > > a particular version of the Rust compiler (the exact version specified
> by
> > > Teaclave and its dependencies). In this sense, releasing it as a
> separate
> > > tool seems a bit overkill. Indeed, it's a bit isolated in terms of
> > > development since it's a rustc plugin rather than anything directly
> > related
> > > to Teaclave. However, I don't think we will need to actively develop it
> > as
> > > we do for the rest part of Teaclave. There is no plan to expand its
> > > functionality, although it does need maintenance because every time
> > > Teaclave updates its toolchain version the internal APIs of rustc
> change.
> > >
> > > With all that said, I do see a point in making the tool as a separate
> > > project. More discussions are welcome!
> > >
> > > Pei
> > >
> > > On Wed, Dec 4, 2019 at 1:46 PM Matt Sicker <bo...@gmail.com> wrote:
> > >
> > >> Whether you'd like to make this part of the project here or externally
> > >> really depends on a few things:
> > >>
> > >> * Licensing: if it's Apache licensed, then not an issue.
> > >> * Community: if it's a tool being developed by only one of the
> > >> committers, then it's fairly difficult for the rest of the community
> > >> to vote on releases for it.
> > >> * Releases: is it released on its own cycle from other repos? If so,
> > >> note what I mentioned about community which can cause releases to get
> > >> delayed waiting for enough votes.
> > >>
> > >> I suspect this component is appropriate to put here. Whether we'd like
> > >> it in its own git repo or not is another question.
> > >>
> > >> On Wed, 4 Dec 2019 at 14:08, Wang Pei <ur...@apache.org> wrote:
> > >>>
> > >>> One of the features MesaTEE (now renamed as Teaclave) promised when
> it
> > >> was
> > >>> initially open-sourced is the so-called "Non-bypassable gateway."
> > >>> Basically, we would like to show that all interactions between the
> TEE
> > >> and
> > >>> the untrusted outside world are properly sanitized in our
> > implementation.
> > >>>
> > >>> As a first step towards this goal, I have implemented a tool that can
> > >>> extract the dependency graph of the crates built by Cargo. It's
> > >>> instrumentation to rustc that analyzes the Rust IR and stores
> > information
> > >>> with an embedded DB such that it can gather information collected by
> > >>> multiple rustc invocations.
> > >>>
> > >>> The tool provides three custom attributes: require_audit, audited,
> and
> > >>> entry_point. These attributes can annotate any item-like entities in
> > Rust
> > >>> code, including ADT, functions, traits, and impl blocks. Starting
> from
> > >> each
> > >>> entry_point, the tool traverses the dependency graph with DFS and
> > emits a
> > >>> warning whenever it encounters an item marked by require_audit unless
> > >>> another item marked by audited presents along the traversal path.
> > >>>
> > >>> The attributes have no effects on code generation and can be safely
> > >> ignored
> > >>> by anyone that does not care about code auditing.
> > >>>
> > >>> About how to publish the tool, there are two options. It can be part
> of
> > >>> mesatee-sgx, the fundamental dependency of the mesatee project. Or it
> > can
> > >>> be released as a standalone tool. In theory, it can be used to audit
> > >> other
> > >>> Rust projects, but I wonder how attractive that would be. Either way,
> > we
> > >>> have to annotate a lot of code in mesatee-sgx and mesatee to make the
> > >> tool
> > >>> acutally useful.
> > >>>
> > >>> Let me know your thoughts.
> > >>>
> > >>> Pei
> > >>
> > >>
> > >>
> > >> --
> > >> Matt Sicker <bo...@gmail.com>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@mesatee.apache.org
> > >> For additional commands, e-mail: dev-help@mesatee.apache.org
> > >>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@mesatee.apache.org
> > For additional commands, e-mail: dev-help@mesatee.apache.org
> >
> > --
> Matt Sicker <bo...@gmail.com>
>
Re: Support for coarse-grained code auditing
Posted by Matt Sicker <bo...@gmail.com>.
There are two things: having a separate git repo (or not), and having it
part of the project or 3rd party. We can have multiple git repos on
apache.org.
On Wed, Dec 4, 2019 at 17:13 Mingshen Sun <bo...@mssun.me> wrote:
> Pei, I think Matt’s point is on the situation if you want to separate this
> project as an individual project.
>
> So, for this tool, I think the question is whether to put it in the
> `apache/incubator-mesatee` repo or a new `apache/incubator-mesatee-xxx`
> repo.
>
> Does this explanation clear to you?
>
> > On Dec 4, 2019, at 2:57 PM, Wang Pei <ur...@gmail.com> wrote:
> >
> > Matt,
> >
> > Thanks for the thoughtful comments.
> >
> > There shouldn't be any problem with licensing. Regarding your other
> > concerns, I have some more information. It's a very tiny tool (about 1300
> > lines of Rust). It provides very limited functionality, and only works
> with
> > a particular version of the Rust compiler (the exact version specified by
> > Teaclave and its dependencies). In this sense, releasing it as a separate
> > tool seems a bit overkill. Indeed, it's a bit isolated in terms of
> > development since it's a rustc plugin rather than anything directly
> related
> > to Teaclave. However, I don't think we will need to actively develop it
> as
> > we do for the rest part of Teaclave. There is no plan to expand its
> > functionality, although it does need maintenance because every time
> > Teaclave updates its toolchain version the internal APIs of rustc change.
> >
> > With all that said, I do see a point in making the tool as a separate
> > project. More discussions are welcome!
> >
> > Pei
> >
> > On Wed, Dec 4, 2019 at 1:46 PM Matt Sicker <bo...@gmail.com> wrote:
> >
> >> Whether you'd like to make this part of the project here or externally
> >> really depends on a few things:
> >>
> >> * Licensing: if it's Apache licensed, then not an issue.
> >> * Community: if it's a tool being developed by only one of the
> >> committers, then it's fairly difficult for the rest of the community
> >> to vote on releases for it.
> >> * Releases: is it released on its own cycle from other repos? If so,
> >> note what I mentioned about community which can cause releases to get
> >> delayed waiting for enough votes.
> >>
> >> I suspect this component is appropriate to put here. Whether we'd like
> >> it in its own git repo or not is another question.
> >>
> >> On Wed, 4 Dec 2019 at 14:08, Wang Pei <ur...@apache.org> wrote:
> >>>
> >>> One of the features MesaTEE (now renamed as Teaclave) promised when it
> >> was
> >>> initially open-sourced is the so-called "Non-bypassable gateway."
> >>> Basically, we would like to show that all interactions between the TEE
> >> and
> >>> the untrusted outside world are properly sanitized in our
> implementation.
> >>>
> >>> As a first step towards this goal, I have implemented a tool that can
> >>> extract the dependency graph of the crates built by Cargo. It's
> >>> instrumentation to rustc that analyzes the Rust IR and stores
> information
> >>> with an embedded DB such that it can gather information collected by
> >>> multiple rustc invocations.
> >>>
> >>> The tool provides three custom attributes: require_audit, audited, and
> >>> entry_point. These attributes can annotate any item-like entities in
> Rust
> >>> code, including ADT, functions, traits, and impl blocks. Starting from
> >> each
> >>> entry_point, the tool traverses the dependency graph with DFS and
> emits a
> >>> warning whenever it encounters an item marked by require_audit unless
> >>> another item marked by audited presents along the traversal path.
> >>>
> >>> The attributes have no effects on code generation and can be safely
> >> ignored
> >>> by anyone that does not care about code auditing.
> >>>
> >>> About how to publish the tool, there are two options. It can be part of
> >>> mesatee-sgx, the fundamental dependency of the mesatee project. Or it
> can
> >>> be released as a standalone tool. In theory, it can be used to audit
> >> other
> >>> Rust projects, but I wonder how attractive that would be. Either way,
> we
> >>> have to annotate a lot of code in mesatee-sgx and mesatee to make the
> >> tool
> >>> acutally useful.
> >>>
> >>> Let me know your thoughts.
> >>>
> >>> Pei
> >>
> >>
> >>
> >> --
> >> Matt Sicker <bo...@gmail.com>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@mesatee.apache.org
> >> For additional commands, e-mail: dev-help@mesatee.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@mesatee.apache.org
> For additional commands, e-mail: dev-help@mesatee.apache.org
>
> --
Matt Sicker <bo...@gmail.com>
Re: Support for coarse-grained code auditing
Posted by Mingshen Sun <bo...@mssun.me>.
Pei, I think Matt’s point is on the situation if you want to separate this project as an individual project.
So, for this tool, I think the question is whether to put it in the `apache/incubator-mesatee` repo or a new `apache/incubator-mesatee-xxx` repo.
Does this explanation clear to you?
> On Dec 4, 2019, at 2:57 PM, Wang Pei <ur...@gmail.com> wrote:
>
> Matt,
>
> Thanks for the thoughtful comments.
>
> There shouldn't be any problem with licensing. Regarding your other
> concerns, I have some more information. It's a very tiny tool (about 1300
> lines of Rust). It provides very limited functionality, and only works with
> a particular version of the Rust compiler (the exact version specified by
> Teaclave and its dependencies). In this sense, releasing it as a separate
> tool seems a bit overkill. Indeed, it's a bit isolated in terms of
> development since it's a rustc plugin rather than anything directly related
> to Teaclave. However, I don't think we will need to actively develop it as
> we do for the rest part of Teaclave. There is no plan to expand its
> functionality, although it does need maintenance because every time
> Teaclave updates its toolchain version the internal APIs of rustc change.
>
> With all that said, I do see a point in making the tool as a separate
> project. More discussions are welcome!
>
> Pei
>
> On Wed, Dec 4, 2019 at 1:46 PM Matt Sicker <bo...@gmail.com> wrote:
>
>> Whether you'd like to make this part of the project here or externally
>> really depends on a few things:
>>
>> * Licensing: if it's Apache licensed, then not an issue.
>> * Community: if it's a tool being developed by only one of the
>> committers, then it's fairly difficult for the rest of the community
>> to vote on releases for it.
>> * Releases: is it released on its own cycle from other repos? If so,
>> note what I mentioned about community which can cause releases to get
>> delayed waiting for enough votes.
>>
>> I suspect this component is appropriate to put here. Whether we'd like
>> it in its own git repo or not is another question.
>>
>> On Wed, 4 Dec 2019 at 14:08, Wang Pei <ur...@apache.org> wrote:
>>>
>>> One of the features MesaTEE (now renamed as Teaclave) promised when it
>> was
>>> initially open-sourced is the so-called "Non-bypassable gateway."
>>> Basically, we would like to show that all interactions between the TEE
>> and
>>> the untrusted outside world are properly sanitized in our implementation.
>>>
>>> As a first step towards this goal, I have implemented a tool that can
>>> extract the dependency graph of the crates built by Cargo. It's
>>> instrumentation to rustc that analyzes the Rust IR and stores information
>>> with an embedded DB such that it can gather information collected by
>>> multiple rustc invocations.
>>>
>>> The tool provides three custom attributes: require_audit, audited, and
>>> entry_point. These attributes can annotate any item-like entities in Rust
>>> code, including ADT, functions, traits, and impl blocks. Starting from
>> each
>>> entry_point, the tool traverses the dependency graph with DFS and emits a
>>> warning whenever it encounters an item marked by require_audit unless
>>> another item marked by audited presents along the traversal path.
>>>
>>> The attributes have no effects on code generation and can be safely
>> ignored
>>> by anyone that does not care about code auditing.
>>>
>>> About how to publish the tool, there are two options. It can be part of
>>> mesatee-sgx, the fundamental dependency of the mesatee project. Or it can
>>> be released as a standalone tool. In theory, it can be used to audit
>> other
>>> Rust projects, but I wonder how attractive that would be. Either way, we
>>> have to annotate a lot of code in mesatee-sgx and mesatee to make the
>> tool
>>> acutally useful.
>>>
>>> Let me know your thoughts.
>>>
>>> Pei
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@mesatee.apache.org
>> For additional commands, e-mail: dev-help@mesatee.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mesatee.apache.org
For additional commands, e-mail: dev-help@mesatee.apache.org
Re: Support for coarse-grained code auditing
Posted by Wang Pei <ur...@gmail.com>.
Matt,
Thanks for the thoughtful comments.
There shouldn't be any problem with licensing. Regarding your other
concerns, I have some more information. It's a very tiny tool (about 1300
lines of Rust). It provides very limited functionality, and only works with
a particular version of the Rust compiler (the exact version specified by
Teaclave and its dependencies). In this sense, releasing it as a separate
tool seems a bit overkill. Indeed, it's a bit isolated in terms of
development since it's a rustc plugin rather than anything directly related
to Teaclave. However, I don't think we will need to actively develop it as
we do for the rest part of Teaclave. There is no plan to expand its
functionality, although it does need maintenance because every time
Teaclave updates its toolchain version the internal APIs of rustc change.
With all that said, I do see a point in making the tool as a separate
project. More discussions are welcome!
Pei
On Wed, Dec 4, 2019 at 1:46 PM Matt Sicker <bo...@gmail.com> wrote:
> Whether you'd like to make this part of the project here or externally
> really depends on a few things:
>
> * Licensing: if it's Apache licensed, then not an issue.
> * Community: if it's a tool being developed by only one of the
> committers, then it's fairly difficult for the rest of the community
> to vote on releases for it.
> * Releases: is it released on its own cycle from other repos? If so,
> note what I mentioned about community which can cause releases to get
> delayed waiting for enough votes.
>
> I suspect this component is appropriate to put here. Whether we'd like
> it in its own git repo or not is another question.
>
> On Wed, 4 Dec 2019 at 14:08, Wang Pei <ur...@apache.org> wrote:
> >
> > One of the features MesaTEE (now renamed as Teaclave) promised when it
> was
> > initially open-sourced is the so-called "Non-bypassable gateway."
> > Basically, we would like to show that all interactions between the TEE
> and
> > the untrusted outside world are properly sanitized in our implementation.
> >
> > As a first step towards this goal, I have implemented a tool that can
> > extract the dependency graph of the crates built by Cargo. It's
> > instrumentation to rustc that analyzes the Rust IR and stores information
> > with an embedded DB such that it can gather information collected by
> > multiple rustc invocations.
> >
> > The tool provides three custom attributes: require_audit, audited, and
> > entry_point. These attributes can annotate any item-like entities in Rust
> > code, including ADT, functions, traits, and impl blocks. Starting from
> each
> > entry_point, the tool traverses the dependency graph with DFS and emits a
> > warning whenever it encounters an item marked by require_audit unless
> > another item marked by audited presents along the traversal path.
> >
> > The attributes have no effects on code generation and can be safely
> ignored
> > by anyone that does not care about code auditing.
> >
> > About how to publish the tool, there are two options. It can be part of
> > mesatee-sgx, the fundamental dependency of the mesatee project. Or it can
> > be released as a standalone tool. In theory, it can be used to audit
> other
> > Rust projects, but I wonder how attractive that would be. Either way, we
> > have to annotate a lot of code in mesatee-sgx and mesatee to make the
> tool
> > acutally useful.
> >
> > Let me know your thoughts.
> >
> > Pei
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@mesatee.apache.org
> For additional commands, e-mail: dev-help@mesatee.apache.org
>
>
Re: Support for coarse-grained code auditing
Posted by Matt Sicker <bo...@gmail.com>.
Whether you'd like to make this part of the project here or externally
really depends on a few things:
* Licensing: if it's Apache licensed, then not an issue.
* Community: if it's a tool being developed by only one of the
committers, then it's fairly difficult for the rest of the community
to vote on releases for it.
* Releases: is it released on its own cycle from other repos? If so,
note what I mentioned about community which can cause releases to get
delayed waiting for enough votes.
I suspect this component is appropriate to put here. Whether we'd like
it in its own git repo or not is another question.
On Wed, 4 Dec 2019 at 14:08, Wang Pei <ur...@apache.org> wrote:
>
> One of the features MesaTEE (now renamed as Teaclave) promised when it was
> initially open-sourced is the so-called "Non-bypassable gateway."
> Basically, we would like to show that all interactions between the TEE and
> the untrusted outside world are properly sanitized in our implementation.
>
> As a first step towards this goal, I have implemented a tool that can
> extract the dependency graph of the crates built by Cargo. It's
> instrumentation to rustc that analyzes the Rust IR and stores information
> with an embedded DB such that it can gather information collected by
> multiple rustc invocations.
>
> The tool provides three custom attributes: require_audit, audited, and
> entry_point. These attributes can annotate any item-like entities in Rust
> code, including ADT, functions, traits, and impl blocks. Starting from each
> entry_point, the tool traverses the dependency graph with DFS and emits a
> warning whenever it encounters an item marked by require_audit unless
> another item marked by audited presents along the traversal path.
>
> The attributes have no effects on code generation and can be safely ignored
> by anyone that does not care about code auditing.
>
> About how to publish the tool, there are two options. It can be part of
> mesatee-sgx, the fundamental dependency of the mesatee project. Or it can
> be released as a standalone tool. In theory, it can be used to audit other
> Rust projects, but I wonder how attractive that would be. Either way, we
> have to annotate a lot of code in mesatee-sgx and mesatee to make the tool
> acutally useful.
>
> Let me know your thoughts.
>
> Pei
--
Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mesatee.apache.org
For additional commands, e-mail: dev-help@mesatee.apache.org
Re: Support for coarse-grained code auditing
Posted by Zhaofeng Chen <zf...@apache.org>.
+1 for putting in `incubator-mesatee` in current stage.
Best,
Zhaofeng
On Wed, Dec 4, 2019 at 1:51 PM Mingshen Sun <bo...@mssun.me> wrote:
> Although this tool is not design for MesaTEE specifically, I still
> think it's better put in the `incubator-mesatee` main repo initially.
> If more people want to use it separately later, we can make it as a
> separate tool. This will simplify the maintenance efforts of the
> project for now.
>
>
> On Wed, Dec 4, 2019 at 12:08 PM Wang Pei <ur...@apache.org> wrote:
> >
> > One of the features MesaTEE (now renamed as Teaclave) promised when it
> was
> > initially open-sourced is the so-called "Non-bypassable gateway."
> > Basically, we would like to show that all interactions between the TEE
> and
> > the untrusted outside world are properly sanitized in our implementation.
> >
> > As a first step towards this goal, I have implemented a tool that can
> > extract the dependency graph of the crates built by Cargo. It's
> > instrumentation to rustc that analyzes the Rust IR and stores information
> > with an embedded DB such that it can gather information collected by
> > multiple rustc invocations.
> >
> > The tool provides three custom attributes: require_audit, audited, and
> > entry_point. These attributes can annotate any item-like entities in Rust
> > code, including ADT, functions, traits, and impl blocks. Starting from
> each
> > entry_point, the tool traverses the dependency graph with DFS and emits a
> > warning whenever it encounters an item marked by require_audit unless
> > another item marked by audited presents along the traversal path.
> >
> > The attributes have no effects on code generation and can be safely
> ignored
> > by anyone that does not care about code auditing.
> >
> > About how to publish the tool, there are two options. It can be part of
> > mesatee-sgx, the fundamental dependency of the mesatee project. Or it can
> > be released as a standalone tool. In theory, it can be used to audit
> other
> > Rust projects, but I wonder how attractive that would be. Either way, we
> > have to annotate a lot of code in mesatee-sgx and mesatee to make the
> tool
> > acutally useful.
> >
> > Let me know your thoughts.
> >
> > Pei
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@mesatee.apache.org
> For additional commands, e-mail: dev-help@mesatee.apache.org
>
>
Re: Support for coarse-grained code auditing
Posted by Mingshen Sun <bo...@mssun.me>.
Although this tool is not design for MesaTEE specifically, I still
think it's better put in the `incubator-mesatee` main repo initially.
If more people want to use it separately later, we can make it as a
separate tool. This will simplify the maintenance efforts of the
project for now.
On Wed, Dec 4, 2019 at 12:08 PM Wang Pei <ur...@apache.org> wrote:
>
> One of the features MesaTEE (now renamed as Teaclave) promised when it was
> initially open-sourced is the so-called "Non-bypassable gateway."
> Basically, we would like to show that all interactions between the TEE and
> the untrusted outside world are properly sanitized in our implementation.
>
> As a first step towards this goal, I have implemented a tool that can
> extract the dependency graph of the crates built by Cargo. It's
> instrumentation to rustc that analyzes the Rust IR and stores information
> with an embedded DB such that it can gather information collected by
> multiple rustc invocations.
>
> The tool provides three custom attributes: require_audit, audited, and
> entry_point. These attributes can annotate any item-like entities in Rust
> code, including ADT, functions, traits, and impl blocks. Starting from each
> entry_point, the tool traverses the dependency graph with DFS and emits a
> warning whenever it encounters an item marked by require_audit unless
> another item marked by audited presents along the traversal path.
>
> The attributes have no effects on code generation and can be safely ignored
> by anyone that does not care about code auditing.
>
> About how to publish the tool, there are two options. It can be part of
> mesatee-sgx, the fundamental dependency of the mesatee project. Or it can
> be released as a standalone tool. In theory, it can be used to audit other
> Rust projects, but I wonder how attractive that would be. Either way, we
> have to annotate a lot of code in mesatee-sgx and mesatee to make the tool
> acutally useful.
>
> Let me know your thoughts.
>
> Pei
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mesatee.apache.org
For additional commands, e-mail: dev-help@mesatee.apache.org