Depending on the product of course, this kind of architecture can be more secure than any of the confidential computing technologies because it does not require syscall shims. Kernel can fully lock-in syscalls however it chooses.
The big issue in "CoC" are these extra layers of software between trusted and untrusted world and complicated kernel stack that goes with them. I never neither fully got why limited set of entry points is such a big deal. You can still take advantage bugs at those entry points and apply attacks like RoP. It's not that different from accessing e.g. a network service with a limited set of requests. AFAIK, they also do get sometimes remotely exploited.
The big issue in "CoC" are these extra layers of software between trusted and untrusted world and complicated kernel stack that goes with them. I never neither fully got why limited set of entry points is such a big deal. You can still take advantage bugs at those entry points and apply attacks like RoP. It's not that different from accessing e.g. a network service with a limited set of requests. AFAIK, they also do get sometimes remotely exploited.
1
0
0
Jarkko Sakkinen
jarkko
Edited 2 years ago
Commercial Linux distribution vendors could bring a lot of confidential computing benefits by providing rate-limited attestation service (i.e. accountless like AMD SEV-SNP CA works) I.e. CA would provide cryptographic proof of the core software stack.
With TPM2 backed hard drive encryption and HMAC encrypted chip communication you get a piece of confidential computing promise, i.e. the software adversary part and you can maintain that promise with pure software bug fixes, which obviously adds in to the value.
The main threat scenario of confidential computing is an adversary with a physical access to the hardware but it is also debatable scenario, and as we all know, there is a lot of data to backup the "debatable" part.
TCG, being a consortium and not a private company, states its specifications that TPM provides resistance against physical attacks. I think this is how Intel, AMD, ARM and other commercial CPU vendors should also describe their corresponding white papers, and make any improvements on top of clear and obvious to the customer.
PS. "confidential computing" is bad terminology but unfortunately it is also defacto terminology of the industry by now. It is actually "trusted computing" because the goal is try to address both confidentiality and integrity problems.
#linux #kernel #tpm #intel #amd #arm #sev #snp #sgx
With TPM2 backed hard drive encryption and HMAC encrypted chip communication you get a piece of confidential computing promise, i.e. the software adversary part and you can maintain that promise with pure software bug fixes, which obviously adds in to the value.
The main threat scenario of confidential computing is an adversary with a physical access to the hardware but it is also debatable scenario, and as we all know, there is a lot of data to backup the "debatable" part.
TCG, being a consortium and not a private company, states its specifications that TPM provides resistance against physical attacks. I think this is how Intel, AMD, ARM and other commercial CPU vendors should also describe their corresponding white papers, and make any improvements on top of clear and obvious to the customer.
PS. "confidential computing" is bad terminology but unfortunately it is also defacto terminology of the industry by now. It is actually "trusted computing" because the goal is try to address both confidentiality and integrity problems.
#linux #kernel #tpm #intel #amd #arm #sev #snp #sgx
1
0
0
@rolle Se on kyllä ihan kiistaton pullonkaula varsinkin pitkässä juoksussa Threadsille, että se on naitettu instaan. Se ei voi olla uusi Twitter ilman Instagram-riippuvuuden poistoa, eikä tarvitse olla kynäniska-niche-nörtti todetakseen tämän. Instahan pyörii siinä 40 pinnassa some-käyttäjissä vähän riippuen mitä tilastoa katsotaan, niin siinä on 60% potentiaalin aukko.
Mun mielestä mihin tahansa pilvipalveluun voi pistää sen oman SSO:n, Metan tapauksessa siis FB tai Insta-loginin, mut myös dedikoitu tunnuksen luonti on ihan välttämättömyys pidemmässä juoksussa, ellei halua keinotekoisia pullonkauloja kasvulle...
Mun mielestä mihin tahansa pilvipalveluun voi pistää sen oman SSO:n, Metan tapauksessa siis FB tai Insta-loginin, mut myös dedikoitu tunnuksen luonti on ihan välttämättömyys pidemmässä juoksussa, ellei halua keinotekoisia pullonkauloja kasvulle...
0
1
2
@kernellogger lol yep, it is my brains off soap opera :-) i have zero idea why i enjoy it...
0
0
1
Jarkko Sakkinen
jarkko
Otin kuukaudeksi Ruutu plussan ja tyttöystävän kanssa käyty läpi hieman suomirealitya:
1. Lejonan luola. Hyvä ohjelma, ja ulkomainen vastine on lempiohjelmia. On tosin moraalisesti kyseenalaista, että yksi leijonista on istuva kansanedustaja Toiset pistävät omaisuutensa pantiksi kampanjoinnin takia, joten risuja tuotantoyhtiölle.
2. Rikkaat ja rutiköyhät. En sano tätä edes vitsillä, kun totean, että on monesti vaikea arvioida, kumpi jakson perheistä on rikas, ja kumpi rutiköyhä. Tämä siksi, koska en tiedä ihmisten henkilökohtaista tasetta. Kaikkea hienoa saa velkarahalla.
#suomi #reality #tv
1. Lejonan luola. Hyvä ohjelma, ja ulkomainen vastine on lempiohjelmia. On tosin moraalisesti kyseenalaista, että yksi leijonista on istuva kansanedustaja Toiset pistävät omaisuutensa pantiksi kampanjoinnin takia, joten risuja tuotantoyhtiölle.
2. Rikkaat ja rutiköyhät. En sano tätä edes vitsillä, kun totean, että on monesti vaikea arvioida, kumpi jakson perheistä on rikas, ja kumpi rutiköyhä. Tämä siksi, koska en tiedä ihmisten henkilökohtaista tasetta. Kaikkea hienoa saa velkarahalla.
#suomi #reality #tv
0
0
0
Jarkko Sakkinen
jarkko
@kernellogger great, i will prioritize drinking glögg then for the upcoming week, and watching seasons of "shark tank" that ive missed :-)
1
0
1
Jarkko Sakkinen
repeated
repeated
Thorsten Leemhuis (acct. 1/4)
kernellogger@fosstodon.org
Edited 2 years ago
#Linux #kernel 6.7-rc7 is out: https://lore.kernel.org/lkml/CAHk-%3DwjDbR1oNZtqTNE4n8MHbzi028JFKSCvyW88hw%2B0GO%3DP%2BA@mail.gmail.com/
"'"[…] since tomorrow is Xmas Eve,[…] I'm doing rc7 on a Saturday instead.
[…] we *could* release a final 6.7 next weekend as per the usual schedule, I'm not going to do that. It's the holidays,[…]
So next weekend is going to be rc8, and I expect that it will be small as nobody should be around.
And then we might get back to a more normal schedule the week after. Maybe.
Please do give it a whirl if you have the time and the energy[…]"'"
1
1
1
@BryanBennett also anything deployed to the cloud has this separation. so you can sort of scientifically/formally say that 99% of time unit tests are run in a contaminated test subject. it is not really an opinion but the actual reality.
0
0
0
Jarkko Sakkinen
jarkko
i don't really have made anything in my professional career that does not require a separate host and target device.
i neither work on IoT space, it was just an example.
i neither work on IoT space, it was just an example.
1
0
0
@BryanBennett @orva To put this in perspective all the testing methodology was invented in a world where embedded systems were essentially something like Intel 8051 with a custom piece of control code written in assembly language and no operating system whatsoever.
0
0
0
@BryanBennett @orva Speaking of full-stack, consider some IoT device, let's say a smart light bulb with a bluetooth speaker and a webcam for the sake of example.
We can run integration tests for it designed for the product right now but essentially a major portion of all possible unit tests written to to the components that encompass its software stack have a total zero value. Sure you can check them in your development system but it has much less value than to run them with the hardware where they are deployed. If unit tests were detachable and deployable you could run (a) your integration test suite and (b) all possible tests written each individual component. That would be a measurable improvement e.g. to the product security metrics.
We can run integration tests for it designed for the product right now but essentially a major portion of all possible unit tests written to to the components that encompass its software stack have a total zero value. Sure you can check them in your development system but it has much less value than to run them with the hardware where they are deployed. If unit tests were detachable and deployable you could run (a) your integration test suite and (b) all possible tests written each individual component. That would be a measurable improvement e.g. to the product security metrics.
1
0
0
@BryanBennett @orva All I'm saying that it is repeated by-design mistake not to design all layers of tests detachable. It was persistent in autotools and the same bad design is repeated e.g. by cargo.
E.g. unit test suite of kernel called kselftest is counter-example of this. It can be run in-tree but can be also packaged and deployed to the target device. So it is not a law of nature but more like bad engineering practice that is common enough to have become a tradition. Just criticising the obvious I guess...
Usually everything I do there is a cross-compiler involved, so even for unit tests there's a hard border between the world where testing happens and the host system, it is more like a law of nature.
E.g. unit test suite of kernel called kselftest is counter-example of this. It can be run in-tree but can be also packaged and deployed to the target device. So it is not a law of nature but more like bad engineering practice that is common enough to have become a tradition. Just criticising the obvious I guess...
Usually everything I do there is a cross-compiler involved, so even for unit tests there's a hard border between the world where testing happens and the host system, it is more like a law of nature.
1
0
0
@orva How do you build BuildRoot/Yocto whatever image without Rust support and deploy test suite as a package? I.e. you are testing on target and do not have the Rust environment there at all.
E.g. just because of this pattern I need to put sometimes GNU make to a test image because test frameworks tend to rely on toolchains.
E.g. just because of this pattern I need to put sometimes GNU make to a test image because test frameworks tend to rely on toolchains.
2
0
0
Jarkko Sakkinen
jarkko
Edited 2 years ago
The most of #autotools based open source software is sort of anti-pattern for QA/CI because the test suite is hard-bound to the source project. This is the reason why I rarely (or almost never) run TPM2 TSS test suite.
I wonder if #rustlang continues to follow this anti-pattern or is there cargo install for the test?
It is sort of thing that has been always bad for anything with disjoint host and target system but is part of “craftmanship” because things has been done that way long enough :-)
1
0
0
Jarkko Sakkinen
jarkko
Edited 2 years ago
I think I will aim at building OS image per CI cycle for keyutils. This guarantees a kernel with configuration options to provide maximum coverage.
For .gitlab-ci.yml I guess it makes sense to then just limit to the branch master i.e. review is manual but red flags will rise up if the reviewer was sloppy :-)
0
0
0