🎙️PODCAST ALERT: Linaro's #virtualization expert Alex Bennée recently featured on the #OpenSource Way podcast where he talked about the emulator project #QEMU and how it helps the open source #software ecosystem. Check out the podcast here 👉 https://ow.ly/zV7h50Wtc2Z

I heard from Himmelblau developers that they are basing their work heavily on tpmrm0, which made me of course happy, as it is one of my contributions some years ago :-)

When I worked on that feature in the Spring of 2017 I thought that nobody will use it, as it is just way too niche, and I could not fully convice myself that it would bring much useful application on top of /dev/tpm0. And there was already IBMTSS and Intel TSS2.

James Bottomley did a lot for this one
in particular tricky dev management code and extended swapper I had put together also for sessions, in addition to objects.

Definitely gives me the needed boost after holiday season to look more into Himmeblau project and gives some faith that I could be useful somehow over time in that ecosystem :-)

#linux #tpm #himmelblau

@mjg59 right, for what is worth Himmelblau itself is implemented with Rust which is probably a good choice to move forward

@mjg59 Microsoft does have Linux Intune client profile but it is a joke. It's missing all the actually interesting crypto capabilities to put this short. As a consequence the official Intune App for Linux is not a target of interests to anyone.

We do need "Edge" functionality tho to communicate with local services and Siemens has implemented that in https://github.com/siemens/linux-entra-sso (Firefox ok'ish, Chrome early phases). This extension can run both on top of intune-portal (daemon that comes with Intune App) and HImmelblau as it is just protocols that matter in that integration."Edge" (or linux-entra-sso) authenticate essentially to a local broker who then talks to MS, and yeah nothing too suprising here really :-)

Himmelblau addresses the problem of Linux Client profile essentially by pretending to be Windows, so it's both software development and reverse engineering (via analysing packet captures) project. Microsoft does not try to purposely shut it down but neither has wanted to endorse it so far, i.e. they are doing just what they always do. :-)

As software project there's two flavours of daemon: other for OAuth with MS-OAPX extensions doing authentication and other doing kerberos renewal, answering queries coming from the cloud (e.g. machine state related queries)

I've been reading and experimenting about a month or something like that (heard first about the project in May), and done modest PR (fixing systemd unit for debian), I wrote above out of my memory just to check what i can still remember from it after coming back from holidays so keep that in mind but i guess this should give some starting points at least :-)

@mjg59 just out of interest and curiosity: have you gathered any experience with himmelblau yet, i.e. the project reimplementing *windows client profile* by the means reverse engineering the protocol with packet traces?

it's just something that has recently (early summer) evolved into a priority topic in my professional life now and in foreseeable near future, thus the interest.

@avlap2 i guess it is working out for you whatever you do. which is great obviously. i'm not debating because nobody is paying for debating at 11:30 PM :-) this is how i've experienced my past life on this topic overall, and it has nothing to do with some imaginary absolute set of correct answers.

@avlap2 yeah so how i see big picture is that i don't think about the tool too much. using excel is as good as using C or Rust if it solves an actual problem.

and it is always good remind oneself that fancy code has zero effect on user experience. and user experience is really everything. so it's IMHO best to "just do something" never mind the too. that's sort of at least my philosophy overall.

even when developing a driver and low-level daemon, only end users define what is great and what is not that great. e.g. better error recovery, failure tolerance etc. map directly to the reporting capabilities on what can be reasonably represented to the user.

users neither base their choices based on how seasoned the developer (or company) is. over-analysing your "level" in any creative or further artistic work is a disease and it helps to recognize this fact.

in music there's of course like spotify shit tracks but there's also like super skilled music which sounds so fucking horrible that you wish you were dead (yngwie malmsteen for one but not mentioning any names here).

@avlap2 it's too broken for that but on leisure time broken is "interesting" :D C is one of the best things a person can experience during lifetime of all experiences known and yet to be discovered but it's a productivity choice here more than anything else ;-)

@avlap2 hell no, it's stuff that i get paid for :-) it's a fucking nightmare to sometimes even compile with that. would not ever try to use it for anything serious that someone is paying for

io_uring's are quite awesome now that i've actually had use case based parallel IO and unpredictable changes and events in the workload and need to react bunch of things along the way. had not used this asset before so could not say really.

As an extension to the current functionality i'd like at recording of USB devices so that you could check optionally for a stick does it have a working image (i.e. record success, IO error and detachment) e.g., for weird situations, i.e. have knowledge base which of the sticks are faulty and which can be safely shared or at least to the best of knowledge.

In this small (last 1.5 weeks it took me) but fun little project I spent a lot of time on getting this right:

Press Ctrl+C to exit.
event=device_detected device=/dev/sda
event=job_started device=/dev/sda
event=job_finished device=/dev/sda result=detached

I.e. distinguishing IO error and detachment ;-) it does have the personal computer user story when you unmount etc. but instead sticks randomly coming and going so getting these right is at least useful when analysing any failure situations. jobs run on io_uring's and uevents through netlink socket bring like the other part of context information.

Nothing too fancy but I created a program called "usb-factory" meant to run as daemon and burn pre-configured images as usb mass storage appears based on image file and some policy. it's meant for instance situation where you need to burn the same image to a bunch of sticks . Obivously it can IPC status of all ongoing parallel writing jobs in order to update some kind of e.g., "burning station kiosk UI" or whatever ;-)

It's in C. I tried Rust but with a lot of string buffer construction going on I have more easier time with overflows ;-) I.e. instead of some language baked policy I want to process string buffer as follows.

Overflow happens => mark and truncate

Then with the condition of overflow marked:
2. More writes => silently drop and success
3. Read => failure
4. Check-and-read => success (as after checking it is cool to read trunacted result as you probably know why you need it).

With these cheap deferred failure semantics I can *design* the reaction to those overflow errors, and make their occurence deterministic. If you have a task manager there's just so much of doing some crazy things small strings and forwarding them as basis of comms so you really need to start to think it as a problem by itself ;-)

Kernel Rust is like a different language (for better) ;-) It does not have any of the above issues.

If I end up doing something at work with Rust in user space that is like actually needed by someone, these days I first write it in C and then rewrite it Rust.

It's just that with C you can touch anything, and thus it is extreme levels fast discover how systems do when you poke them.

In kernel things are obviously different as there is just one thing your tickling ;-)

I'm doing a small thingie to help out mutt with email using Zig. It's something i was going to do in any possible situation, so thought to spice it up like this. It's of scale that i can fully finish it and never look back zig again if i don't want to, and large enough so that i know if the language makes sense at all.

It's a bit similar case as lsiommu, i.e. scripts that have been making my life worse for over 10 years and now I'm "reimagining" them ;-)

This way I get those wiped away from my backlog and learn something new in the process.

#zig #mutt #email

lsiommu provides now also json output:

❯ build/lsiommu | head -10
Group 000 Address 0000:00:07.1 Class 060400 ID 8086:9a25 Revision 01
Group 001 Address 0000:00:07.0 Class 060400 ID 8086:9a23 Revision 01
Group 002 Address 0000:00:02.0 Class 030000 ID 8086:9a49 Revision 01
Group 003 Address 0000:00:00.0 Class 060000 ID 8086:9a14 Revision 01
Group 004 Address 0000:00:04.0 Class 118000 ID 8086:9a03 Revision 01
Group 005 Address 0000:00:0a.0 Class 118000 ID 8086:9a0d Revision 01
Group 006 Address 0000:00:0d.0 Class 0c0330 ID 8086:9a13 Revision 01
Group 006 Address 0000:00:0d.2 Class 0c0340 ID 8086:9a1b Revision 01
Group 007 Address 0000:00:0e.0 Class 010400 ID 8086:9a0b Revision 00
Group 008 Address 0000:00:14.0 Class 0c0330 ID 8086:a0ed Revision 20

~/work/github.com/puavo-org/lsiommu master
❯ build/lsiommu --style json | head -10
{
        "iommu_groups": [{
                        "id":   0,
                        "devices":      [{
                                        "address":      "0000:00:07.1",
                                        "class":        "060400",
                                        "vendor":       "8086",
                                        "device":       "9a25",
                                        "revision":     "01"
                                }]

better not to tag 1.0.0 yet to leave room for command-line interface and output formatting tweaks although now it is “feature complete”.

#linux #iommu

@kidney with I added it together with sysfs discovery:

❯ build/lsiommu -h
Usage: build/lsiommu [-h]
Lists IOMMU groups and their associated PCI devices.
This version was compiled for sysfs discovery.

-h, --help Print help and exit

@kidney actually i somehow manage forgot to implement that. i'll add it back with sysfs support :-) thanks for notifying

this felt super counter-productive:

https://github.com/puavo-org/lsiommu/blob/master/udev.c

does libudev have mechanism to get directly a packed representation?

#linux #udev #pci