Move non-attestation functions out of AA #468
Conversation
There was a problem hiding this comment.
There seems to be some duplication between the gRPC and ttRPC implementations, but I guess that's ok.
There was a problem hiding this comment.
Right. Before this PR, we put mod grpc and mod ttrpc inside one same file attestation/mod.rs with different mod blocks to implement like attestation proto APIs. Also, main() functions were put in src/grpc.rs and src/ttrpc.rs. In this PR, I bring the two mod blocks out and put into different files. And also bring grpc and ttrpc binaries into different rust binary targets rather than a same binary controlled by grpc/ttrpc feature. I think it would be more clear from viewpoint of file structure personally. wdyt? cc @jialez0
Xynnn007
force-pushed
the
refactor-aa
branch
2 times, most recently
from
7497b96
to
53c766c
Compare
Xynnn007
force-pushed
the
refactor-aa
branch
from
53c766c
to
be4a488
Compare
|
|
||
| - name: Run cargo test | ||
| uses: actions-rs/cargo@v1 | ||
| with: | ||
| command: test | ||
| args: --features openssl,rust-crypto,offline_fs_kbc,kbs,coco_as -p attestation-agent -p attester -p coco_keyprovider -p kbc -p kbs_protocol -p attestation_agent -p crypto -p resource_uri -p sev@0.1.0 | ||
| args: --features openssl,rust-crypto,all-attesters,kbs,coco_as -p attestation-agent -p attester -p coco_keyprovider -p kbc -p kbs_protocol -p crypto -p resource_uri |
There was a problem hiding this comment.
I don't see the offline_fs_kbc or offline_sev_kbc being tested in the CDH workflow. Do we need to add that?
There was a problem hiding this comment.
I will add some unit tests to offline_fs_kbc, which will be enabled by default for CDH without specifying features explicitly.
offline_sev_kbc will not be used so it will not be test.
The original code of online_sev_kbc does not have any tests. The test will enable sev feature, which will cover the tests of online_sev_kbc.
Xynnn007
force-pushed
the
refactor-aa
branch
2 times, most recently
from
c78fd35
to
43da2a7
Compare
|
cc @jialez0 |
Xynnn007
force-pushed
the
refactor-aa
branch
from
26cfca0
to
f04ba71
Compare
After moving non-attestation related functionalities from AA to CDH, it is time to delete these functionalities from AA, including the following 1. KBCs 2. abilities to access KBS Signed-off-by: Xynnn007 <xynnn@linux.alibaba.com>
Xynnn007
force-pushed
the
refactor-aa
branch
2 times, most recently
from
ce39eba
to
6f98b56
Compare
AA binary was a separate crate named `app`. For rust we can use binary section https://doc.rust-lang.org/cargo/reference/cargo-targets.html#binaries to specify the binary built based on the crate. This commit will combine `app` and `lib` crate into `attestation-agent` lib. This will help users use a unambiguous crate name. Signed-off-by: Xynnn007 <xynnn@linux.alibaba.com>
Now AA does not support KBCs and only have attestation related functions. Thus we define a new flag named `ATTESTER` in AA's Makefile to specify the attester plugin. Signed-off-by: Xynnn007 <xynnn@linux.alibaba.com>
Signed-off-by: Xynnn007 <xynnn@linux.alibaba.com>
After moving non-attestation abilities from AA to CDH, we do not need offline-fs-kbc in AA. Instead, it is in CDH now. Also, test will not cover sev crate as it is now not used. Fixes the related crate names. Signed-off-by: Xynnn007 <xynnn@linux.alibaba.com>
Signed-off-by: Xynnn007 <xynnn@linux.alibaba.com>
Currently, not all TEEs support initdata mechanism. Thus we add a result enum named `InitdataResult` that has three results - Result::Ok(InitdataResult::Ok): initdata mechanism is supported and check ok. - Result::Ok(InitdataResult::Unsupported): initdata mechanism is not supported on this platform - Result::Err(_): error occurs when checking initdata Signed-off-by: Xynnn007 <xynnn@linux.alibaba.com>
The other half work for #412
cc @jialez0