Jarkko Sakkinen
Posts
4728Following
319Followers
489OpenPGP: 3AB05486C7752FE1
Jarkko Sakkinen
jarkko
i feel like a winner now when I reached TPM_RC_INTEGRITY. this is easy to squash :D crypto works fully or does not work at all
0
0
0
Jarkko Sakkinen
jarkko
day 2 fighting with TPM2_Import. and it's not the first time. the protocol crate is doing nothing wrong, it's a bug in tpm2sh
0
0
0
Jarkko Sakkinen
jarkko
I should have remember by now that for KDFa's you feed "DUPLICATE\0" not "DUPLICATE" and so forth. But no, I fought with TPM_RC_VALUE for half a day.
0
0
0
Jarkko Sakkinen
jarkko
Edited 11 days ago
this SVG garbage fuck. is there something we could put .gitattributes, .gitignore or something that would make it not to destroy git grep experience?
2
0
0
Jarkko Sakkinen
jarkko
Edited 12 days ago
Now it is carved to the stone:
https://github.com/puavo-org/tpm2sh/commit/f95d6aae1f5212c39349a77e066b4ceeb2ef580c
I'll need this once I have bandwidth to refine:
https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/
https://github.com/puavo-org/tpm2sh/commit/f95d6aae1f5212c39349a77e066b4ceeb2ef580c
I'll need this once I have bandwidth to refine:
https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/
0
0
0
Jarkko Sakkinen
jarkko
Edited 12 days ago
In the sense confidential computing holds it promise that since the hardware is inaccessible by practical means to *everyone*, you need to execute that type of code in your head. It is as confidential at least as computing can ever get [Side-note: even the name of the field is incorrect terminology at least when reflecting on how the terminology is usually defined in the field of information security. The so called "CIA Triad" defines trust as the sum of availability, confidentiality and integrity.]
This is what I literally do with SGX patches:
1. I pick up Intel SDM (which is IMHO pretty good ISA reference overall, zero complains on that).
2. I read the pseudocode for new opcodes or revisit old ones.
3. I look it is applied in kernel patch
4. Finally I "hallucinate" its execution :-----)
And based on this mental execution procedure I ack/nak patches.
You can extrapolate from this that probably most of any type of CoC code in kernel are the least audited areas of the Linux kernel source code. Even if working for a CPU company, it is hard to really hammer the code, if your only access to the hardware is a shitty company cloud.
This is what I literally do with SGX patches:
1. I pick up Intel SDM (which is IMHO pretty good ISA reference overall, zero complains on that).
2. I read the pseudocode for new opcodes or revisit old ones.
3. I look it is applied in kernel patch
4. Finally I "hallucinate" its execution :-----)
And based on this mental execution procedure I ack/nak patches.
You can extrapolate from this that probably most of any type of CoC code in kernel are the least audited areas of the Linux kernel source code. Even if working for a CPU company, it is hard to really hammer the code, if your only access to the hardware is a shitty company cloud.
0
0
0
Jarkko Sakkinen
repeated
repeated
Jarkko Sakkinen
jarkko
OOPS
it was more than TPM_RC_SIZE :-)
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?id=9ba073e0d924fbeeff4f74a70bc76bbf29380862
0.10.5 released
BR, Jarkko
it was more than TPM_RC_SIZE :-)
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?id=9ba073e0d924fbeeff4f74a70bc76bbf29380862
0.10.5 released
BR, Jarkko
0
0
0
Jarkko Sakkinen
jarkko
Edited 12 days ago
Software crypto would really need its own "official" systemd service as that way any application could have audited crypto. I.e. crypto operations would be executed by that service and results returned back to the caller. It could probably be just user service running inside session in order to guarantee better privacy.
This is partly because Rust does not have a proper DSO support, and this would address this flaw in Rust. It is not a question how great some random crate is but more like can you make software that can be used in production as per standards that companies use.
E.g., I cannot recommend to use tpm2sh to use anything else except kernel testing for this exact reason no matter how the crates are implemented or how well I might orchestrate the calls.
This is partly because Rust does not have a proper DSO support, and this would address this flaw in Rust. It is not a question how great some random crate is but more like can you make software that can be used in production as per standards that companies use.
E.g., I cannot recommend to use tpm2sh to use anything else except kernel testing for this exact reason no matter how the crates are implemented or how well I might orchestrate the calls.
1
0
1
I.e. in short what is done, is done. It cannot be changed. However we should ask a lot more than we ask today from CPU vendors and add constraints and clauses a lot more.
E.g, when accepting a feature it would be a great policy to stop accepting feature improvements if they play like this.
E.g, when accepting a feature it would be a great policy to stop accepting feature improvements if they play like this.
1
0
3
Jarkko Sakkinen
jarkko
Edited 12 days ago
IMHO learnings from SGX, SNP and TDX: we should simply stop accepting enterprisy CPU features UNLESS there's guaranteed flow of reasonably priced SDPs, EVEN if they are not profitable for the CPU company.
E.g., in SGX, Intel delivered exactly one generation of NUCs in order to comply what we agreed on at Linux Plumbers 2016. Once the feature was in the mainline it was end of story for developer accessible hardware. And still after that SNP and TDX have been included, which is plain stupid.
It's hard to take away user facing code from kernel once it is included but it would be the best possible policy and constraint to take only bug fixes up until we have cheap SDPs for the confidential computing CPU features.
Let's shutdown any other improvements up until that. Not a decision maker on x86 tree but I have right for my opinion at least :-)
EDIT: I think I make my case without "PS" part :-) This is still how things have went and based on facts (I've witnessed the whole process).
#linux #kernel #intel #amd
E.g., in SGX, Intel delivered exactly one generation of NUCs in order to comply what we agreed on at Linux Plumbers 2016. Once the feature was in the mainline it was end of story for developer accessible hardware. And still after that SNP and TDX have been included, which is plain stupid.
It's hard to take away user facing code from kernel once it is included but it would be the best possible policy and constraint to take only bug fixes up until we have cheap SDPs for the confidential computing CPU features.
Let's shutdown any other improvements up until that. Not a decision maker on x86 tree but I have right for my opinion at least :-)
EDIT: I think I make my case without "PS" part :-) This is still how things have went and based on facts (I've witnessed the whole process).
#linux #kernel #intel #amd
1
0
4
Jarkko Sakkinen
repeated
repeated
Jukka Niiranen
jukkan@mstdn.social"Who needs an App Store? You've got the Nokia PC Suite software on a CD-ROM! Just plug the proprietary cable into your Symbian S60 device, boot up your Windows PC, and away you go. THIS is the smartphone experience for people who are serious about mobile computing."
#Nokia #Symbian #smartphone #retrophone
0
3
0
This would be much better integration step for TPM2 than having a separate driver on Rust side. We could start with tpm2-cmd1/cmd2, then move on to tpm2-space.c i.e. get all structural processing inside Rust.
tpm2_protocol is light on definitions and should not need any kernel specific Rust shenanigans.
Consider it as value like integer but just a bit more complex internaal represention but in the end it is just a value.
tpm2_protocol is light on definitions and should not need any kernel specific Rust shenanigans.
Consider it as value like integer but just a bit more complex internaal represention but in the end it is just a value.
0
0
0