Jarkko Sakkinen
Posts
4480Following
316Followers
475OpenPGP: 3AB05486C7752FE1
Jarkko Sakkinen
jarkko
When I have had to use Windows I've WSL2 totally inconvenient environment to work in with a number of things breaking up badly. A regular VM works much better and shell access goes by SSH.
That said I think as a technology it is a great piece still. I'd see for it more use if there was way to make Windows applications that would embed Linux kernel as a run-time.
It could e.g. be used to deliver accurate software versions of hardware consumer products, which tend to run Linux quite often...
That said I think as a technology it is a great piece still. I'd see for it more use if there was way to make Windows applications that would embed Linux kernel as a run-time.
It could e.g. be used to deliver accurate software versions of hardware consumer products, which tend to run Linux quite often...
0
0
0
Jarkko Sakkinen
jarkko
Personally, I think that these new bc replacements make me feel more like Cobol vibes with "1 kilometer - 1 meter" type of expression support than modern vibes...
0
0
0
SGX/TDX and SEV-SNP are far from useless as hardware products but both fail to deliver to de-facto measure how things are cleared up in the security world: transparency. In both the transparency is not blocked by technologies being closed. It is blocked by not having cheap off-the-shelf hardware to try out the CPU features. One can objectively claim that these are the weaker parts of the arch-code, not because of unskilled developers but because of very small audience who tests these features in the wild.
0
0
0
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 1 year 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 1 year 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