A smoke test for trusted keys: https://gitlab.com/jarkkojs/linux-tpmdd-test/-/commit/b737d6ca4f45fa171e623f8e1038801edf17c323

Running:

cmake -Bbuild && make -Cbuild buildroot-prepare
pushd build/buildroot/build
make
images/run-tests.sh

Runs successfully at least with my master, containing the HMAC encryption patches.

Failing in in-progress asymmetric key branch so had to extend the test to cover trusted keys (vs. writing commands manually):

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/?h=tpm2_key

#linux #kernel #tpm #keys

I emailed to James Prestwood if he wants to rebase just the ops part from his patch set. My patch does the reorg and defines parser and key type so that is exactly left so better to ask. I also was also wondering TPM2_RSA_Decrypt vs TPM2_Sign/TPM2_VerifySignature. The old patch set uses the former.

Depending on response I'll take that patch from him or refactor it myself.

Submitted abstract to #ethprague CfP. I own 0 ETH 🤷 #Linux and authentication related stuff. #ethereum

And there is also other angle to this: would it be possible partition resources for a CPU core so that it would do RTIC in one thread as it was running on a single core CPU on bare metal, which is also pretty interesting problem. I think I look at Jailhouse hypervisor implementation for this one...

I.e. I'm not claiming that it can be done. It is just that by reflecting with different tool you really get to the bottom of the bottlenecks, constraints and limitations. Just because it is fun and learning I guess...

Learned a cool trick in Python, if need to have more deterministic latency for a thread: shutdown the gc as prologue and do collection once as epilogue.

I.e.

gc.disable()
# Do stuff that does not cause CPU
# exceptions or interrupts.
gc.collect()

I also noticed that MicroPython has pretty usable inline assembler.

This makes me wonder if you could implement Python version of https://rtic.rs/2/book/en/ running hard real-time tasks on bare metal.

This is more like learning thing than challenging thing… I.e. by doing the similar thing perhaps in limited scope in other language it is easier to get grip of the original target…

#python #rustlang

@briankrebs right, and to add, if you have a criminal court case ongoing shut f*ck up until it is done and finished. you might end up saying stupid things on internet that can be potentially used against you as evidence. no wonder the security was flawed...

@briankrebs apparently that ceo has yet to find mastodon ;-) social suicide commentary in every other possible social media. he should author a book called "how to f*ck up your life and beyond"

A 26-year-old Finnish man was sentenced to more than six years in prison today after being convicted of hacking into an online psychotherapy clinic, leaking tens of thousands of patient therapy records, and attempting to extort the clinic and patients.

https://krebsonsecurity.com/2024/04/man-who-mass-extorted-psychotherapy-patients-gets-six-years/

Even though Julius "Zeekill" Kivimaki has a cybercrime rap sheet thicker than a dictionary, he will end up serving roughly half that time, because all that stuff he did before he turned 18 doesn't count toward first-time offender status.

BTW, the CEO of the now-bankrupt psychotherapy practice was prosecuted as well (database credentials "root/root") but received a suspended sentence.

@signalapp in linux. (once we add x509 support for TPM2, probably 6.11) the CPU certificate delivery could be even delivered with a public key coming from TPM (private key non-existent in the machine). So you could hardware-to-hardware pipeline.

hmm... https://www.phoronix.com/news/Linux-610-TPM-Encrypt-Integrity. so it is not yet pulled so no need to announce in the current state "unfinished work" (by definition, given that it is not pulled) ;-)

I'll try to get asymmetric keys soon out which cleans this stack up further as a side-effect. If this did not make into 6.10 then I'll just add it on top of that patch set.

@signalapp also e.g. signal would benefit in qa if there was emulated infrastructure in place (my previous post). not that well tested except field tested ofc.

@signalapp like for instance: https://signal.org/blog/building-faster-oram/. none of this applies unless proven otherwise for every single running instance of the client. or if you have a belief system applied.

The single biggest issue in confidential computing is still. that there is no legit way to deliver cryptographic proof to client/browser inherited from CPU attestation. i.e. a x509 certificate. and so that it is vendor-neutral. not sure if even @signalapp can do this. who cares what you run in the backend if you cannot prove it.

this is still somewhat solid reference: https://www.decentriq.com/article/swiss-cheese-to-cheddar-securing-amd-sev-snp-early-boot

I wonder if it would make sense to elf stamp kernel images with some sort of. identifier to check where the image is at in the mainline reflecting to the latest of https://docs.kernel.org/process/cve.html. Or maybe this already exist. It would make in the mainline perhaps because then you could detect "too old" when running multiple distributions.

Which gives you an infrastructure to differentiate emulated attested from production attested. So even attestation is technically possible but at minimum unattested version which is just upgrading qemu would help a lot.

I.e. it cannot force you from not setting "fake stamp" but it can refuse to give attestation to it if you don't set it. Intel won't sign it for you plain and simple.

In SGX attestation, which mostly applies also to TDX, you could possibly use e.g. enclave attribute for this defined by the ISA spec (Intel SDM). I mean for the "fake stamp". Attestation can refuse to attest if the provision matches to some list inside archiectural enclave (aka Intell signed) but that "fake stamp" attribute is not set.

because of the hard-bound bare metal depeendency quality assurance in the real sense of that word like super-transparent does not exist in this world for confidential computing no wonder it is confidential when it is not even measured by most of the qa infrastructure existing. totally fights against the marketing promise.