this is how i'm reorganizing tpm2_library that i resurrected yesterday:

protocol
├── Cargo.toml
└── src
├── envelope
│   ├── create_primary_command.rs
│   ├── create_primary_response.rs
│   ├── create_response.rs
│   ├── dictionary_attack_lock_reset_command.rs
│   ├── empty_response.rs
│   ├── flush_context_command.rs
│   ├── get_capability_command.rs
│   ├── get_capability_response.rs
│   └── mod.rs
├── lib.rs
├── object
│   ├── creation_ticket.rs
│   ├── mod.rs
│   ├── tpm2b_data.rs
│   ├── tpm_alg_id.rs
│   ├── tpma_object.rs
│   ├── tpml_pcr_selection.rs
│   ├── tpms_sensitive_create.rs
│   └── tpmt_public.rs

and further:

1. object "registry" is a flat and fat given that there is standard body doing "intelligent hashing", i.e. TCG is my UUID algorithm for that directory. agreed that the de-facto names are ugly but it is ugly AND clean :-) it is known to scale with the spec from the get go to foreseeable future making it ugly, clean and super stable.
2. all objects marshal and unmarshhal.
3. envelope is also flat as i have unidirectionality as constraint and both commands and responses translate bytestream and back.

this api is aimed to work for clients and emulators. i have no interest to write a simulator but it's still easy to figure out how to make that useful: the same crate can be used to implement TPM interaction and tests can use it to mock the TPM chip interaction :-)

[and it will appear to gitlab anytime soon]

#tpm #linux #tss

I also realized that I've been misguided by the driver i've made myself because it works as expected, i.e. isolates concurrent users from accessing each other cryptographi assets. used pre-existing tpm stacks for results and many default to apparently to /dev/tpmrm0 🤷 And I don't really understand why I did not put it in first place to Gitlab for which I know even how to run local instance.

I’m finally updating tpm2_library crates which provide near spec idiomatic naming balanced with Rust conventions, marshalling/unmarshalling, parsing displaying error codes with parameter numbers etc.

The protocol crate is aiming to be no_std style IO free crate. In fact I aim to polish it to the level that it would be equally useful and complete for both clients and TPM emulators to take advantage of and given the use purpose having super-conservative list of deps:

[dependencies] bitflags = { workspace = true } strum = { workspace = true } strum_macros = { workspace = true }

The idea how naming goes is easiest to demostrate with TPM_CC type form TPM2 Structures specification. Let’s randomly pick TPM_CC_EvictControl, which is use for transient-persistent and persistent-evicted conversions.

EDIT: So, uhm, I’ll setting it up the project to Gitlab. Was doing too many things at once :-) I moved the repo away from Codeberg some weeks ago to get more CI quota basically but Github was not the right move. Gitlab is a better fit because I already do kernel CI there, keyutils is hosted in Gitlab and I’ve had less luck running actions locally with “act” than “gitlab-ci-local” (https://github.com/firecow/gitlab-ci-local).

I have already placeholder for it in Gitlab but it is probably better sleep first and do after (and make sure that everything works).

[*] https://github.com/ColinIanKing/tpm2-scripts Thanks for @colinianking again for preservation! It came for use now …

#tpm #linux #kernel

@notbobbytables in learning there's like two axes (or this is how i project learning at least): the axe of learning and the axe of learning how to learn ;-)

@notbobbytables the differentiating factor to those optimization guides (while not disregarding them by any means) is that it's really good writeup and really a perfected piece of text :-) e.g., it would be a great text to read in order to gain some of the gist of memory optimizations before reading technical guides such as the ones you linked.

i don't know if you've ever read "linkers and loaders" by stephen levy but it is also something i did enjoy many years ago (and still have hard copy) for being great text to get the gist of structure of executable binaries, which really gave me "philosophical" foundation to navigate in manuals and specification.

and some years earlier while at high school, i got my foundation for code optimization with pipeline architectures from https://www.goodreads.com/book/show/946151.Graphics_Programming_Black_Book.

these are more like guides to "read the actual guides" that build the foundation to read any optimization manuals, technical papers, specs and similar documentation :-)

@notbobbytables yeah well it's almost unique identifier, isn't it? :-)

or like "t-shirt level unique" even :-) would be odd if there was another cpumemory.pdf.

probably the most time standing tutorial i've ever read is cpumemory.pdf. still from time to take a peak on it because it is such a great refresher :-)

Without “| xargs -n 1 basename” would change the output stream to absolute path. With that in mind:

function cargo-registry
  argparse 'a/all' 'q/query=' -- $argv
  or return
  set -l q ""
  if set -q _flag_query
    set q "$_flag_query"
  else
    set q "$argv[1]"
  end
  set -l r \
    ~/.cargo/registry/src/index.crates.io-*/
  set -l dirs
  if set -q _flag_all
    set dirs (ls -d $r*/ 2>/dev/null)
  else
    set dirs (
      ls -d $r*/ 2>/dev/null \
      | xargs -n 1 basename
    )
  end
  if test -z "$q"
    printf '%s\n' $dirs \
    | sort
  else
    printf '%s\n' $dirs \
    | grep -i "$q" \
    | sort
  end
end

Results:

~ main
❯ cargo-registry | head -5
ab_glyph_rasterizer-0.1.9
ab_glyph-0.2.31
accesskit_consumer-0.28.0
accesskit_macos-0.20.0
accesskit_winit-0.27.0

~ main
❯ cargo-registry -a | head -5
/Users/jarkko/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ab_glyph_rasterizer-0.1.9/
/Users/jarkko/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ab_glyph-0.2.31/
/Users/jarkko/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/accesskit_consumer-0.28.0/
/Users/jarkko/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/accesskit_macos-0.20.0/
/Users/jarkko/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/accesskit_winit-0.27.0/

~ main
❯ cargo-registry egui
egui_glow-0.32.0
egui-0.32.0
egui-wgpu-0.32.0
egui-winit-0.32.0

~ main
❯ cargo-registry egui -a
/Users/jarkko/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/egui_glow-0.32.0/
/Users/jarkko/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/egui-0.32.0/
/Users/jarkko/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/egui-wgpu-0.32.0/
/Users/jarkko/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/egui-winit-0.32.0/

Fun fact: Finnish signal intelligence agency is called "SIGINT"

This is a fish function:

function cargo-registry --argument-names query
  set -l r \
    ~/.cargo/registry/src/index.crates.io-*/
  set -l c (
    ls -d $r*/ 2>/dev/null \
    | xargs -n 1 basename
  )

  if test -z "$query"
    printf '%s\n' $c \
    | sort
  else
    printf '%s\n' $c \
    | grep -i "$query" \
    | sort
  end
end

And what it does is:

❯ cargo-registry|head
ab_glyph_rasterizer-0.1.9
ab_glyph-0.2.31
accesskit_consumer-0.28.0
accesskit_macos-0.20.0
accesskit_winit-0.27.0
accesskit-0.19.0
adler2-2.0.1
adler2-2.0.1
ahash-0.8.12
ahash-0.8.12
aho-corasick-1.1.3
allocator-api2-0.2.21
allocator-api2-0.2.21
anstream-0.6.19
anstream-0.6.19
anstyle-1.0.11
anstyle-1.0.11
anstyle-parse-0.2.7
anstyle-parse-0.2.7
anstyle-query-1.1.3
# ...

And also:

❯ cargo-registry egui
egui_glow-0.32.0
egui-0.32.0
egui-wgpu-0.32.0
egui-winit-0.32.0

#fish #shell

derive_more is a gem when it comes to rust crates

makes is so much less involved

@aakoskin I.e. I autolabeled USB topology in real-time (through uevents and udev database) and had a way to set labels and yeah ... not very smart :-)

@aakoskin It is but I somehow "knowingly" realized this while working on with USB stack as such a huge limitation :-) so yeah, this is stating the obvious if you want to put it that way.

USB is interesting in the way that identifying USB devices is a non-existent feature.

E.g., a librarian for USB mass storage would have to base identifying to filesystem labels, and obviously user would have to have a process for labeling for that to actually work.

And if a malicious stick is attached, as long as it provides sane description of itself (i.e. naming a legit device, vendor, class etc.), computer can't tell the difference.

https://d2lang.com/

This is as done as lsiommu can ever be, or at least as far as I’m concerned so it’s a release time:

https://github.com/puavo-org/lsiommu/releases/tag/1.0.0

I.e. I spent last night making it do less from the almost nothing it was doing already ;-) That’s the point of these tools…

That enumerated to:

• Reverted back to heap sort.
• Carved 64 kB of data section for JSON builder.
• Hammered STRING_BUFFER() to migrate most of the strings to stack (except JSON builder
• Bunch of fixes…

This sums up to zero mallocs from the main application (while libudev probably does bunch of them when not compiled with make DISCOVER=sysfs).

Motivation to do was this shitty python script:

#!/usr/bin/env python3
#
# Copyright (c) 2022-2023 Jarkko Sakkinen <jarkko.sakkinen@iki.fi>

import os
import sys

IOMMU_SYSFS = '/sys/kernel/iommu_groups'
IOMMU_GROUP_MAX = 128 # an arbitrary choice

def get_iommu_devices():
    groups = [None for group in range(IOMMU_GROUP_MAX)]

    with os.scandir(IOMMU_SYSFS) as group_it:
        for group in group_it:
            devices = []

            group_sysfs = IOMMU_SYSFS + '/' + group.name + '/devices'
            with os.scandir(group_sysfs) as device_it:
                for device in device_it:
                    devices.append(device.name)

            index = int(group.name)
            if index >= IOMMU_GROUP_MAX:
                print('Overflow')
                sys.exit(1)

            groups[index] = devices

    return groups

if __name__ == "__main__":
    groups = get_iommu_devices()

    for i in range(len(groups)):
        group = groups[i]
        if group == None:
            break

        print('IOMMU Group %d' % (i))

        group.sort()

        for device in group:
            # FIXME: Replace with pure Python code:
            os.system('lspci -nns ' + device)

#linux #kernel #iommu #kvm

I'm happy now with mailweb for my own needs but I wrote down in detail the tasks for expanding it to TUI file managers:

https://codeberg.org/jarkko/mailweb/issues

I could easily cope with approaches if it makes sense to me. I just wrote, mainly as a reminder, steps to a working implementation done if I really had to :-)

i'll add text/plain support to mailweb in the next update. it's obsolete feature for mutt or aerc but for file manager such as midnight command and ranger that'll make it a generic email file opener as it shows eml/mbox files correctly (i.e. with pics not cids).

With "--browse" it just forwards the result to the mime handler.

i wanted to change the name of my html mail tool multidepart as it is used by some funding organization or similar:

https://www.eiturbanmobility.eu/projects/multidepart/

the new name is mailweb as it is a tool that literally does that i.e., it converts text/html mail to a static website (despite archaic) ;-)

https://crates.io/crates/mailweb

also bumped the minor to add clarity for the change.

Through some indeterministic process that I don't understand from time to time I have to "warn up" gpg to not fail on "git tag -s" like this:

❯ git tag -s ihatemylife
error: gpg failed to sign the data
error: unable to sign the tag
The tag message has been left in .git/TAG_EDITMSG

~/work/codeberg.org/jarkko/multidepart main ⇡
❯ gpg -s README.md

After the latter command, tag signing suddenly works.

#git #gpg #yubikey