@kernellogger @vbabka lol, ok ok, won't forget this i promise! 🔀 🤠

@vbabka point taken :-)

One more PR for v6.10: https://lkml.org/lkml/2024/6/5/78

#linux #kernel #tpm

Can't probably go wrong with GPLv2 I guess.

I wonder what is the policy of putting something to scripts/ (not to vmlinux) that is written with #Rust? I.e. build time utility. Just curious.

And actually, since bindgen is installed from crates.io, not from kernel tree, should it be actually submitted there, and not to the kernel tree?

Kernel documentation gives pretty bad rationale for bindgen being in Cargo: “The bindings to the C side of the kernel are generated at build time using the bindgen tool. A particular version is required.” I’m sure there are good reasons to install it using cargo but why the documentation does not list those reasons, no matter how obvious they might be to some.

So I guess I put my build time tool to crates.io because at least first it is an experiment, and secondly bindgen is managed like this. But even this does not conclude the story fully. I have no idea in what license that out-of-tree pulled build-time utility is expected to be. It is not documented, or at least I cannot find it documented anywhere.

#rustlang #linux #kernel

@jani Wow, nice list of people in the loop you have over there...

@jani @TheKeymaker And to further underline: for parts that are not obvious, there must be also a solid reason why they are not obvious. I.e. those parts exist no matter how well the semantics are implemented. Otherwise, it should not IMHO pass the patch review process in the first place... I'm not saying that accepting such functions never happens to me but this is at least the ideal...

@jani @TheKeymaker Documentation should merely document the parts that are neither obvious nor intuitive. This applies both to an inline comment and also header comment of a function...

@jani OK, did not check the implementation. I thought the point was to find the nearest power of two.

I’d probably use __fls() and << 1 unless the exact same number (i.e. already pow2). Like for the stuff I thought it was used for to be more specific… I guess I stay away from those functions, feels for me more complicated to use them than do what I want open-coded :-) Probably would end up using them in a wrong way…

Today I might start experimenting with procedural macros in #Rust, and generating opcodes with them :-)

And also keep it compiling with gccrs, if by any means possible (not going to hang myself to this tho).

#rustlang #kernel

Given how wide they are spread, neither make sense to fix the naming. Something simple like roundup and roundup_pow2 would already bring some clarity.

Ofc you could make an inline function with a "better name", which calls round_up, and let subsystems progressively transform to that but probably not worth of time and energy :-)

@jani NO. I had to check never used them. I've done round_up manually :-) Actually where I've done manual "rounding", I'd rather keep it the way it is, than switch because it makes later on easier to recall... So I have question their usefulness actually but I don't mind them being there.

OK, I guess this solves the problem: https://eips.ethereum.org/EIPS/eip-2718

So much math, too little plumbing ;-)

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.

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.

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

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.

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

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 :-)