Raymond P. Burkholder - Things I Do

Lifted from Installing Virtio Drivers for Windows on Proxmox to Enable Paravirtualization / Fix Incorrect Memory Monitoring, there is a section at the end which discusses settings for disk caching modes in Proxmox. The terms relate to how frequently data is flushed to the underlying storage system. There are trade-offs for performance and durability.

• Direct sync - highest data security but has poor performance - ensures that every time data is written to memory, it is immediately synchronized to the disk. This means each write operation introduces disk latency because the system must wait for the disk to confirm the write is complete before continuing with other operations. Although this method provides the highest data security, frequent disk operations lead to lower performance.
• Write through - balance between data consistency and performance - writing data to memory and immediately writes it to disk without waiting for disk confirmation. It offers good data consistency and high performance by reducing the time spent waiting for disk confirmation. However, disk write operations still occur, leading to some performance overhead.
• Write back - improves performance but comes with certain data risks - first writes data to the memory cache and writes it back to the disk at an appropriate time. This reduces the number of disk accesses and improves system performance. However, because data is cached in memory, there is a risk of data loss if the system crashes or experiences a power outage before writing back to the disk.
• Write back (unsafe) - highest performance (fastest among all modes) but compromises data security and consistency - similar to the regular write back method, but it makes no guarantees about data consistency. This means that in the event of a system failure or power outage, data not yet written back to the disk could be permanently lost. While this method provides higher performance, it sacrifices data security and consistency. RamFS would be a use case here.

Perform your own testing given your own physical infrastructure and weigh the pro's and con's.

Starting with version VE 8.4, proxmox host directories can be shared into a windows or linux virtual machine. I have a version 9 running here as an example:

# pveversion
pve-manager/9.0.6/49c767b70aeb6648 (running kernel: 6.14.8-2-pve)

Check to see that the appropriate package is installed, it should be by default:

# dpkg -l | grep virtiofsd
ii  virtiofsd         1.13.2-1      amd64     Virtio-fs vhost-user device daemon

Create a directory for sharing, use something like /mnt or /var/local, depending upon your preference:

# mkdir /var/local/shared

In the proxmox management site, navigate Datacenter -> Directory Mappings, then add a mapping with the directory just created. The name supplied will be the name seen in the virtual machine.

Also in the proxmox management site, navigate to the virtual machine settings -> Hardware and add a Virtiofs Filesystem Passthrough. Select the directory id you just created. Select the 'Direct IO' box (may be optional). Then restart the machine if already started to have the setting take effect.

In a Windows virtual machine, be sure you've installed the Windows VirtIO Drivers.

Open the Services cmdlet (services.msc). There should be a 'VirtIO-FS Service". Startup type can be set to automatic. If only temporary use is required, simply start the service. A new device should become visible in This PC in file explorer.

For Windows based virtual machines, WinFSP is required. It is mentioned at How to install virtiofs drivers on Windows.

Once installed, open services.msc, and start the VirtIO-FS Service

In explorer, you should see the shared data folder in 'This PC'.

Risk Manager for Intrusion Tolerant Systems: Enhancing HAL 9000 with New Scoring and Data Sources

Intrusion Tolerant Systems (ITSs) have become increasingly critical due to the rise of multi-domain adversaries exploiting diverse attack surfaces. ITS architectures aim to tolerate intrusions, ensuring system compromise is prevented or mitigated even with adversary presence. Existing ITS solutions often employ Risk Managers leveraging public security intelligence to adjust system defenses dynamically against emerging threats. However, these approaches rely heavily on databases like NVD and ExploitDB, which require manual analysis for newly discovered vulnerabilities. This dependency limits the system's responsiveness to rapidly evolving threats. HAL 9000, an ITS Risk Manager introduced in our prior work, addressed these challenges through machine learning. By analyzing descriptions of known vulnerabilities, HAL 9000 predicts and assesses new vulnerabilities automatically. To calculate the risk of a system, it also incorporates the Exploitability Probability Scoring system to estimate the likelihood of exploitation within 30 days, enhancing proactive defense capabilities.

Despite its success, HAL 9000's reliance on NVD and ExploitDB knowledge is a limitation, considering the availability of other sources of information. This extended work introduces a custom-built scraper that continuously mines diverse threat sources, including security advisories, research forums, and real-time exploit proofs-of-concept. This significantly expands HAL 9000's intelligence base, enabling earlier detection and assessment of unverified vulnerabilities. Our evaluation demonstrates that integrating scraper-derived intelligence with HAL 9000's risk management framework substantially improves its ability to address emerging threats. This paper details the scraper's integration into the architecture, its role in providing additional information on new threats, and the effects on HAL 9000's management.

This is an interesting take on security: toleration of intruders to systems. I suppose this is somewhat akin to limiting blast radius. One interesting nugget:

... system applies a proactive recovery mechanism to protect the system from undetected attacks. A central controller periodically rotates the state of each VM, transitioning between active, cleansing, ready, and active states.

This would be the pre-emption step of what file checksum utilities would do. However, this doesn't eliminate the types of intrusions where intruders make use of elevated account access.

AI agentic programming is an emerging paradigm in which large language models (LLMs) autonomously plan, execute, and interact with external tools like compilers, debuggers, and version control systems to iteratively perform complex software development tasks. Unlike conventional code generation tools, agentic systems are capable of decomposing high-level goals, coordinating multi-step processes, and adapting their behavior based on intermediate feedback. These capabilities are transforming the software development practice. As this emerging field evolves rapidly, there is a need to define its scope, consolidate its technical foundations, and identify open research challenges. This survey provides a comprehensive and timely review of AI agentic programming. We introduce a taxonomy of agent behaviors and system architectures, and examine core techniques including planning, memory and context management, tool integration, and execution monitoring. We also analyze existing benchmarks and evaluation methodologies used to assess coding agent performance. Our study identifies several key challenges, including limitations in handling long context, a lack of persistent memory across tasks, and concerns around safety, alignment with user intent, and collaboration with human developers. We discuss emerging opportunities to improve the reliability, adaptability, and transparency of agentic systems. By synthesizing recent advances and outlining future directions, this survey aims to provide a foundation for research and development in building the next generation of intelligent and trustworthy AI coding agents.

Open Questions about Time and Self-reference in Living Systems

Living systems exhibit a range of fundamental characteristics: they are active, self-referential, self-modifying systems. This paper explores how these characteristics create challenges for conventional scientific approaches and why they require new theoretical and formal frameworks. We introduce a distinction between 'natural time', the continuing present of physical processes, and 'representational time', with its framework of past, present and future that emerges with life itself. Representational time enables memory, learning and prediction, functions of living systems essential for their survival. Through examples from evolution, embryogenesis and metamorphosis we show how living systems navigate the apparent contradictions arising from self-reference as natural time unwinds self-referential loops into developmental spirals. Conventional mathematical and computational formalisms struggle to model self-referential and self-modifying systems without running into paradox. We identify promising new directions for modelling self-referential systems, including domain theory, co-algebra, genetic programming, and self-modifying algorithms. There are broad implications for biology, cognitive science and social sciences, because self-reference and self-modification are not problems to be avoided but core features of living systems that must be modelled to understand life's open-ended creativity.

I've done some pre-seeding to be able to auto-install Debian on bare metal and as virtual machines. Using classes is a useful addition for conditional execution of configuration management.

What you probably ought to be doing instead is specifying the option you want via the `classes` setting (an alias for `auto-install/classes`), and then implementing the behaviour you want by setting `preseed/run` in a minimal preseed.cfg, and having a script do whatever you want in response to the classes= setting you specified. So your preseed.cfg would just be:

d-i	preseed/run	string start.sh

and your start.sh would be something like:

#!/bin/sh
. /usr/share/debconf/confmodule

db_get auto-install/classes
db_set preseed/include "${RET:-default}".cfg;;

(you might want to check that the value of $RET makes sense before using it)

Then the real configs go in `default.cfg` and `alternative.cfg` (assuming you're planning on specifying `classes=alternative`)

You may be able to get inspiration from here: https://hands.com/d-i/

although the class handling there is quite deeply buried.

Here's a simpler example of using preseed/run to do odd things to D-I, that while not involving classes, is easier to follow: https://hands.com/d-i/bug/846002/

BTW `auto-install/classes` is reserved for users (it is not used by D-I internally), so it's there specifically for you to implement whatever scheme you like.

Additional information on pre-seeding can be found at B.2. Using preseeding.

A reference for my future self for some interesting troubleshooting capability

When triggering the issue please issue as well a Alt+SysRq+t to dump a list of current tasks and their information to the log. (on systems where you do not have the SysRq key, it might be the PrintScreen one). You need to enable as well debugging dumps, so have to enable it:

echo 8 > /proc/sys/kernel/sysrq

then once you have triggered the crash issue a Alt+SysRq+t and provide the log got over the netconsole.

More information on SysRq key hacks: https://docs.kernel.org/admin-guide/sysrq.html

Lastly, since you have a efi system, we might take as well advantage of logging via pstore. It seems active on your system, so check on next crash please as well /var/lib/systemd/pstore directory for fresh crash logs.

For pstore: https://docs.kernel.org/admin-guide/pstore-blk.html and systemd-pstore.service(8).

... so let's go the bisect route, I will replicate the excellent small howto from Uwe Kleine-Koenig here.

The whole will involve to compile multiple kernels. First we need to prepare a config for your system and to prepare the respective upstream versions, in your case we want to bisect the stable versions in one specific branch, so we can shortcut, and we know we want to bisect changes between 6.12.35 and 6.12.38 in your case.

    git clone --single-branch -b linux-6.12.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
    cd linux-stable
    git checkout v6.12.35
    cp /boot/config-$(uname -r) .config
    yes '' | make localmodconfig
    make savedefconfig
    mv defconfig arch/x86/configs/my_defconfig

As a fist step now compile a local 6.12.35 to ensure it is "good".

    # test 6.12.35 to ensure this is "good"
    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install the resulting .deb package and confirm the problem is not present.

And now the same for the version you suspect is broken, is "bad" for git bisect speach.

    # test 6.12.38 to ensure this is "bad"
    git checkout v6.12.38
    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install the resulting .deb package and confirm the problem with audio exists.

So we have now a range of from good to bad kernel and we can start the bisect:

    git bisect start v6.12.38 v6.12.35

    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install, try to boot and verify the state of the problem

and if the problem is hit run:

    git bisect bad

    git bisect good

Please pay attention to always select the just built kernel for booting, it won't always be the default kernel picked up by grub.

Then provide the output of

    git bisect log

In the course of the bisection you might have to uninstall previous kernels again to not exhaust the disk space in /boot. Also in the end uninstall all self-built kernels again.