Jarkko Sakkinen
Posts
4695Following
319Followers
484OpenPGP: 3AB05486C7752FE1
@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...
0
0
1
@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...
1
0
1
@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…
0
0
1
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 :-)
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 :-)
0
0
0
@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.
1
0
1
OK, I guess this solves the problem: https://eips.ethereum.org/EIPS/eip-2718
0
0
0
Jarkko Sakkinen
jarkko
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
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
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
jarkko
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
jarkko
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
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
jarkko
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 :-)
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
@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
Jarkko Sakkinen
repeated
repeated
Jon Greig
jgreig@ioc.exchangeNIST 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