TPM2 command encoding with #bincode and #serde:
let options = DefaultOptions::new()
.with_fixint_encoding()
.with_big_endian();
buf.extend(&options.serialize(&(Tag::NoSessions as u16)).unwrap());
buf.extend(&options.serialize(&22_u32).unwrap());
buf.extend(
&options
.serialize(&(CommandCode::GetCapability as u32))
.unwrap(),
);
buf.extend(&options.serialize(&(Capability::Handles as u32)).unwrap());
buf.extend(&options.serialize(&HR_PERSISTENT).unwrap());
buf.extend(&options.serialize(&1_u32).unwrap());
The work on #bootc Is coming along very nice! This morning keynote by @cgwalters, Dan Walsh, and Stef Walter was very nice to see the current state of it in #Fedora and CentOS Stream. #devconf_cz
#neovim in #fedora 40 does this when opening a #lua file:
Error detected while processing BufReadPost Autocommands for "*":
Error executing lua callback: /usr/share/nvim/runtime/filetype.lua:35: Error executing lua: /usr/share/nvim/runtime/filetype.lua:36:
BufReadPost Autocommands for "*"..FileType Autocommands for "*"..function <SNR>1_LoadFTPlugin[20]..script /usr/share/nvim/runtime/f
tplugin/lua.lua: Vim(runtime):E5113: Error while calling lua chunk: /usr/share/nvim/runtime/lua/vim/treesitter/language.lua:107: no
parser for 'lua' language, see :help treesitter-parsers
stack traceback:
[C]: in function 'error'
/usr/share/nvim/runtime/lua/vim/treesitter/language.lua:107: in function 'add'
/usr/share/nvim/runtime/lua/vim/treesitter/languagetree.lua:111: in function 'new'
/usr/share/nvim/runtime/lua/vim/treesitter.lua:41: in function '_create_parser'
/usr/share/nvim/runtime/lua/vim/treesitter.lua:108: in function 'get_parser'
/usr/share/nvim/runtime/lua/vim/treesitter.lua:416: in function 'start'
/usr/share/nvim/runtime/ftplugin/lua.lua:2: in main chunk
[C]: in function 'nvim_cmd'
/usr/share/nvim/runtime/filetype.lua:36: in function </usr/share/nvim/runtime/filetype.lua:35>
[C]: in function 'nvim_buf_call'
/usr/share/nvim/runtime/filetype.lua:35: in function </usr/share/nvim/runtime/filetype.lua:10>
stack traceback:
[C]: in function 'nvim_cmd'
/usr/share/nvim/runtime/filetype.lua:36: in function </usr/share/nvim/runtime/filetype.lua:35>
[C]: in function 'nvim_buf_call'
/usr/share/nvim/runtime/filetype.lua:35: in function </usr/share/nvim/runtime/filetype.lua:10>
stack traceback:
[C]: in function 'nvim_buf_call'
/usr/share/nvim/runtime/filetype.lua:35: in function </usr/share/nvim/runtime/filetype.lua:10>
Press ENTER or type command to continue
A crate for #TPM 2.0 library protocol, or beginnings of it: https://gitlab.com/jarkkojs/tpm2_library/
Sub-crates:
tpm2_call
for TPM 2.0 library protocol shenanigans.tpm2_cli
for a command-line interfaces.Development process:
I aim to do cli first as Linux tied but it could also have e.g. Windows backend. tpm2_call
will be portable between operating systems.
So for my TPM2 crate I was thinking to rename the project Git as tpm2_library
and have sub-crates tpm2_call
for protoco and tpm2_cli
with a sub-command tpm2cli rc
.
Is it acceptable to name for consistency sake the sub-crate directory as tpm2_cli
but generate an executable as tpm2cli
?
Root project’s name inherits from https://trustedcomputinggroup.org/resource/tpm-library-specification/
I initiated my own #TPM2 #Rust crate partly because the output given by tpm2_rc_decode does not give back the mnemonic of a return code.
Here’s the example from its man page:
tpm2_rc_decode 0x1d5
tpm:parameter(1):structure is the wrong size
So I wrote my return code decoder, and here’s how it works with the previous example:
target/debug/examples/tpm2rc 0x1d5
TPM_RC_SIZE
The Git-repository is available here: https://gitlab.com/jarkkojs/tpm2_call
I’m not going to add any code this crate dealing with /dev/tpm0
. Instead the plan is to implement command buffer builder and parser with similar high-level ideas as I’ve done in the #Linux #kernel.
📣 Only 2 days (today and tomorrow) left to get your talk proposals in for the All Systems Go! 2024 CFP.
The clock ⏲️ is ticking!
🏃♂️ Hurry over to get yours in: https://cfp.all-systems-go.io/all-systems-go-2024/cfp