Posts
4497
Following
316
Followers
475
Linux kernel hacker and maintainer etc.

OpenPGP: 3AB05486C7752FE1
So much math, too little plumbing ;-)
1
0
0

Jarkko Sakkinen

Edited 1 year ago

Other thing that puzzles in #Ethereum and #Swarm is that why waste bandwidth and CPU cycles to #JSON when you could #ASN1 the transaction like:

Root ::= SEQUENCE {
  from INTEGER
  to INTEGER
  value INTEGER
  gas INTEGER
  gasPrice INTEGER
  nonce INTEGER
  data OCTET STRING
  chainId INTEGER
}

Pretty trivial scalability optimization IMHO. Maybe I submit another talk just to say that hey use ASN1.

1
0
0
It does neither need a new generation of TPM chips as those chips only store a set on random seed from which primary keys are derived. A firmware update would enable it.
0
0
0
The thing that I was driving that it would be cool idea to add TPM_ECC_SECP_256_K1 curve to Table 4 of TCG Algorithm Registry ;-) So not more or less than that. That would pretty much make any TPM2 chip a crypto wallet.

E.g. Microsoft has already efforts ongoing to enable Ethereum in Edge browser and they are also investing to TPM2 in Bitlocker. So I'd expect that this would be a no-brainer also for Microsoft. And it would be few lines of code to extend this to also manage Ethereum, Bitcoin and other similar rooted blockchains by the kernel keyring: https://lore.kernel.org/linux-crypto/20240528210823.28798-1-jarkko@kernel.org/T/#t
1
0
0

Jarkko Sakkinen

Presentation at ethprague was well received. I was surprised but happy. It was based on equal opportunity in crypto. Not for ethereum per se. Im all for marketplace based on equal opportunities applying cryptographic primitives, which is a fair standingpoint.
1
0
2

Jarkko Sakkinen

Edited 1 year ago
I might give a shot on ASN.1 decoder rewrite in Rust. Might take a while. But it is in backlog :-) It is just a simple bytecode VM and callbacks to C code. I also think that it might be possible to implement it fully gccrs-compatible because it does pretty trivial stuff and no real I/O because it lives in a sandbox.

Also, here the cool part considering is really the ASN.1 compiler, which could take advantage of procedural macros to spit out snippet of that bytecode. Because it is part of kbuild shenanigans it could be enabled potentially earlier than actual Rust features in vmlinux.

Doing this might also be a way to find better guidelines on how to use Rust in kernel.

#linux #kernel #Rust #rustlang
0
0
0

Jarkko Sakkinen

I don't actually drive "lust" but yeah I'd take model from WebKit how they treat C++, heavily and conservatively limiting its "advanced features".

Then gccrs would need to be on par only on that subset to be enabled for kernel build, which is first and foremost important thing for defconfig.

I implemented first versions of WebGL support back in 2010 for QtWebKit, which then spread to GtkWebKit and EFLWebKit. From that background I know how nicely that project copes with C++ and its crazy features :-)
0
0
1

Jarkko Sakkinen

0
1
2
@kornel that could be feasible in constraints if they did not break ABI purposely. They’ve documented that even as a feature. Changing symbol mangling is ABI annihilation. Should have never touched that.
0
0
0
@leeloo @vathpela Oh no, even mangling is not sealed but has versions: "Mangling versions'. For unmangled symbols you can even script some binary analysis tasks. Rust's language team takes apparently care that binary analysis is not only more complicated but also any automation on that will also break over time.
0
0
0

NIST said it has awarded a new contract to an outside vendor that will help the federal government process software and hardware bugs added to the National Vulnerability Database (NVD).

NIST wouldnt say which vendor was hired

https://therecord.media/nist-nvd-backlog-clear-end-fiscal-2024

0
1
0

@lorddimwit Nothing against Zig but we apparently chose Rust.

I still think we should fork Rust and strip it down like hell. Then it would not be compatible with Rust but more like relative. I don’t see any problem in that I mean even C is not at least formally a subset of C++, they have some differences in semantics

I don’t care about languages (except little bit of C which is lingua franca for ABI) but I’m more like worried:

  1. Experienced maintainers in file systems, mm etc. with no time at hands are not able to do proper analysis on Rust. So we are going to the unknown without “shared consensus” being on the steering wheel.
  2. It has tons of “never use this in kernel” crap, which we IMHO should just remove from it. Who care if we end up something NOT Rust but still relative or similar to Rust.
  3. Language spec is out of control… and in Github ;-)
  4. Compiler bugs are a disease. That huge ever growing language spec maintains their steady flow.
  5. It will be tedious job to maintain correspondence with gccrs and rustc. Even if you think that LLVM should be everywhere (which is no-go for linux but just for the sake of example), how do you do ever detect all those nasty compiler bugs?

We need something more compact that does not change often so that also compiler’s implementation can be matured, bugs fixed etc. So yeah, to sort out this madness I really do personally (this is my voice only, not korg as org) think that we should stop this madness and just do a fork and control all that in kernel mailing lists. Linux would deserve language of its own, relative to Rust but not always compatible…

0
1
2
@leeloo @vathpela

Yes all that crap piles up to put short. Read about binary analysis, compilers, linkers, ELF ABI specs etc. and you should get a grip.
1
0
0

-> @atom@mk.absturztau.be

If Windows XP was released in 2024

6
12
2
@kornel Traits and generics would still need some mangling but limiting their features we could possibly get the symbols in the ELF binary have names that would be more familiar and meaningful and more C alike instead of following C++ convention like Rust does. Right and I think unwrap() should not exist as any default behavior is harmful, especially panic. So yeah there would be lot of stuff that could be simply wiped away and get a better language for kernel dev.
1
0
0
@kornel We could keep the features from Rust that make sense ofc and remove those that don’t and get a tighter language spec which is less prone to often ignored compiler bugs when discussing about safety properties. By freezing the language with a fork of Rust, it would be also easier to keep ”lustc” and ”gccls” in sync (if the fork was called ”lust” for the sake of example).
1
0
0
@kornel well for kernel we need only fallible allocations, namespaces could be taken away (and causes need for symbol mangling), no use for external crates, we don’t use cargo because vmlinux is self-contained, we don’t use rust’s atomic type. There’s alot of harmful features in Rust for kernel. Just randomly picked a few.
1
0
0

Jarkko Sakkinen

The worst part of any trip ongoing: departing home. The best part of any trip is yet to come: arriving home. ✈️
0
0
1
@vathpela Oh, and then we could run the development of language spec and the compiler frontends in total three mailing lists (e.g. lust-lang@vger.kernel.org, lust-gcc@vger.kernel.org and lust-llvm@vger.kernel.org).

Github makes following the language development with easy ways to backtrack years old discussons almost impossible or you really have to put effort to it vs. just going to lore and grabbing a mbox.gz of a relevant discussion.

I really wish I would live in this nice and lusty alternate reality instead of this crappy and rusty reality ;-)
0
0
0
Show older