Posts
4983
Following
329
Followers
494
Linux kernel hacker and maintainer etc.

OpenPGP: 3AB05486C7752FE1

Jarkko Sakkinen

Edited 1 year ago
@mjg59 Reported to https://support.signal.org/hc/en-us/requests/new. Not holding my breath, probably will be plain ignored...

Also "protecting from 3rd parties via SGX" does not hold in the case of Signal as they have their own data centers. Physical machine is already an enclave if you own it. Plain TPM2 would do.

So there's no actual scenario with SGX for Signal that make sense, plain and simple. Providing CPU attestation to client user would be such scenario, or if Signal was using 3rd party data centers. So it is provably only marketing that they use SGX, and has been that since 2017 when Moxie was around.

Fake marketing scam by definition.
0
0
0
My bug fixes to the paging code where included to the upstream of the project so not all went wrong!
0
0
1
Obviously not for mainline but since the project compiles the full kernel it would be easier to carry downstream kernel patch rather than have separate OOT driver. Tried to explain this but it went to deaf ears...
1
0
0

Jarkko Sakkinen

Edited 1 year ago

I fixed some bugs in page tables of RISC-V Keystone enclaves (bootstrapping code of page tables) last Fall to get them working with CVA6 RISC-V CPU, and now I get steadily emails from people who are trying to use Keystone but cannot get it working for various reasons.

Not blaming those people but clearly the project is not too community oriented 🤷 I try respond politely that I don’t have the bandwidth.

Does not come as surprise tho because I wrote a trivial in-kernel driver PoC to which project showed no interest, still continuing with their OOT-drver:

Cannot recall which one was newer version because it is such a long time since I wrote these :-)

#riscv #keystone #enclave #linux

1
0
4

I love it that my play stats on Bandcamp look like an MSEG envelope curve.

0
1
0

Jarkko Sakkinen

Submitted a security issue to Signal App about the privacy issue on how they use Intel SGX :-) Let's see how this goes...
1
0
1

⚡️ 🇦🇷 A theft of a radioactive material capsule in Buenos Aires, Argentina has raised concerns among the population. The capsule contained a 45ml container of radioactive liquid and was stolen from a nuclear medicine company. Authorities have been alerted and are investigating the incident. https://www.riskmap.com/incidents/2132301/articles/222305988/

0
2
0
@ChrisF Yeah, exactly, totally misguided advice...
0
0
1

New development policy: code generated by a large language model or similar technology (e.g. ChatGPT, GitHub Copilot) is presumed to be tainted (i.e. of unclear copyright, not fitting NetBSD's licensing goals) and cannot be committed to NetBSD.

https://www.NetBSD.org/developers/commit-guidelines.html

1
21
3
And yeah, be skeptical towards people who categorize other people as hobbyists and engineers :-)
0
0
2

Jarkko Sakkinen

Edited 1 year ago
"No Arduino! If you aim to master embedded systems, Arduino won’t cut it. It’s a playground for hobbyists, not the battleground for engineers. The purpose is not to scare you — It’s to help you out. It is to give you a proper direction." -https://medium.com/@umerfarooqai/embedded-engineering-roadmap-say-no-to-arduino-a0eed8e1bf10

Well, that at least scares me. How I think is that one should take the simplest possible tool to get a PoC.

Otherwise, all energy might be consumed in useless and pointless battles. Conserving energy, prioritizing and picking the right battles is what engineers IMHO do.

#arduino #engineer
2
0
2

Jarkko Sakkinen

Last bit from my side for TPM2 asymmetric keys: https://lore.kernel.org/linux-crypto/20240515150213.32491-1-jarkko@kernel.org/T/#u

Now I'll wait for some patches from James Prestwood based on his previous work: https://lore.kernel.org/keyrings/20200518172704.29608-1-prestwoj@gmail.com/
0
0
1

Jarkko Sakkinen

Edited 1 year ago
0
0
2

Jarkko Sakkinen

Edited 1 year ago
Pull request 4/4 pulled this time for asymmetric keys :-) https://lkml.org/lkml/2024/5/15/699

My PR's were in chaos about a year ago, and Linus also complained about the quality. This was mostly because the startup I was in went out of business and lots of stuff going on in life overall but I've gradually improved my process to make it more fail-safe. Results start to show and four PR's to four subsystems was a non-issue :-)

In the next life crisis: I'm prepared
0
0
1
@pid_eins tiny embedded, Kernel QA, testing pre-production hardware that is in FPGA (not yet ASIC) the sweet spot is a static multi-call binary. And also sort of like Chrome web browser works :-)

I'd really have to actually try the upstream to get a better picture what is going on. as said, i only really know what the distro enables for me so i might be totally lost with this.

Also in the higher end of the scale, i.e. latest Xeon and EPYC server hardware a static mult-call binary would bring a *huge* security benefit: systemd could be bootstrapped as it is inside SGX/TDX/SNP enclave and fully attested, encrypted and integrity protected. It would bring "infrastructure security" to systemd that can protect from many attack vectors due software bugs.
0
0
0
@kernellogger Rust community will learn one lesson eventually: a pole position must be maintained because there is this thing called "competition" ;-) Rest of the world lives by measured facts. Pretty amazing how great static analysis for plain C has gotten in GCC14. And for plain C it can only get better given that the language spec does not grow constantly.
0
0
1

Jarkko Sakkinen

Edited 1 year ago
@jejb @kernellogger @pid_eins For reference this is how I test upstream: https://gitlab.com/jarkkojs/linux-tpmdd-test. I often branch this locally and then add/remove some stuff but yeah this is the context. Would be counter-productive to add systemd, even if it gave me support for unit-files.
0
0
0

Jarkko Sakkinen

Edited 1 year ago
@jejb @kernellogger @pid_eins Right to be in phase what is going on in systemd it would need to replace this multicall binary called "busybox" which is defacto for kernel testing. Otherwise I hear about features when they get enabled in stock distributions (for the most part) :-)

Nothing wrong in systemd but it just don't cut in fast-phased kernel QA cycle. If there was "microd" that would be a drop-in replacement for busybox, that would work. This a niche where systemd *does not* dominate. No time to follow every possible thing but as user I'm happy with it.

Actually it would have benefits over busybox, even if it was somewhat rigged and stripped off. The main issue with busybox is that it cannot obviously re-use unit files from upstream projects. So you need to sometimes launch daemons manually or rewrite init in sysvinit.

A topology of two multicall static binaries would not be outrageous for kernel testing: "microd" doing systemd alike stuff and busybox providing the command-line tools. It would be still pretty trivial to deploy even without a build system.
1
0
0
Show older