fidzu : debian

A feature on modern PCIe implementations is "Resizable BAR" AKA "REBAR". This basically means that instead of allocating 256MB of address space for a PCIe device to have it's memory mapped the device can ask for more, the limit can be 4G with some hardware or the combination of motherboard and expansion card can support 64bit addressing to allow the entire memory space of a GPU to be mapped in one region. Directly mapping all the memory will be faster no matter how things work, but a combination of algorithms optimised for a flat memory layout and overheads from remapping can cause 90% of performance to be lost without REBAR support. Some GPUs (or maybe the software driving them) will even refuse to work without it.

I believe that almost all hardware supporting DDR4 will support REBAR at a hardware level, but in many cases the BIOS doesn't support it. There are people who have reflashed a system BIOS to add REBAR support and there are options to use a modified UEFI boot loader to replace the code that is used for mapping the GPU memory.

The systems I like to use are server grade tower systems with registered ECC RAM, after a few years they become quite cheap and still give decent performance while supporting large amounts of RAM. But many such systems that could support REBAR don't, presumably because the vendor doesn't have a great interest in supporting new uses of old hardware.

Comparing the Name Brand Servers

The HP Z640 and Z840 systems I'm running date from 2014 and give good performance with replacement CPUs that are cheap on ebay, but they don't support REBAR without a flashed BIOS. The next release of those HP servers are the HP Z6 and Z8 Gen 4 systems from 2017 that have BIOS support for enabling REBAR.

The Lenovo Thinkstation Px20 (P520, P920, etc) don't support REBAR which is especially disappointing as they were on sale from 2017 to 2022 and have decently fast CPUs. The replacement for the Px20 systems are the ones that are still on sale now and they seem likely to have REBAR support - but won't be affordable on ebay.

The Dell PowerEdge T440 and R740 systems (and presumably all their servers from 2017) don't support REBAR. There are no google hits for T550 and R750 systems from 2021, so presumably no complaints means that Dell servers from that era support it. But the T350 servers are junk and only take slow CPUs, and the T550 systems are brutally expensive. The Precision 5520 systems don't support it and newer Precision workstations will get expensive.

It seems that HP is best for this.

Which HP Workstation

The Z2 G4 only supports 64G of RAM so isn't worth considering.

The Z4 G4 is low end and comes in two variants. The one with i5/i7/i9 CPUs doesn't support ECC RAM so isn't suitable for me, and that probably means most Z4 G4 systems on the market. The upside is that apparently 2*6pin PCIe power cables is standard so any size GPU should work and there are 8 DIMM slots supporting up to 512G of RAM. There are 3 options for PSU, 490w for 0 GPUs, 750W for 2 (small) GPUs, and 1000W for up to 4 GPUs.

The Z6 G4 has an option for a second CPU that almost no-one selects, that reduces the space for RAM so there's only 6 DIMM slots. But as there is no option for a Z6 without ECC RAM every one on offer will be good.

The Z8 G4 is a nice dual socket system that I would not use for a serious GPU after my experience of my Z840 having a motherboard problem from a big GPU.

The Z4 G4 is going for about $500 on ebay with the 750W PSU, that is more than I want to pay but not a lot more. In 6 months they could be going for $350 or so. There are hardly any Z6 G4 systems on offer and they are all well over $1000 so I'm not considering them.

Conclusion

I need to poll the second hand sites for Z4 G4 systems and find one going cheap. One of those could be a good ML test machine for a while and then become a workstation once the faster CPUs (which are currently around $900) become cheap.

04 May 2026 8:22am GMT

I have just learned of the Copy Fail kernel vulnerability [1] thanks to alexanderkjall@mastodon.social (who I have just followed on Mastodon and I recommend that you follow too). The question for me (after installing the patched kernel the systems of mine that are most exposed) is whether SE Linux would have stopped that.

Basic Policy Analysis

For the SE Linux policy analysis the alg_socket class is the one that is related to the exploit. So the following policy analysis command (run as non-root with policy copied to /tmp from a running system) shows what domains are allowed access on my current Debian development system:

$ sesearch -A -c alg_socket /tmp/policy.35 
allow NetworkManager_t NetworkManager_t:alg_socket { accept bind create read setopt write };
allow bluetooth_t bluetooth_t:alg_socket { accept append bind connect create getattr getopt ioctl listen read setattr setopt shutdown write };
allow daemon init_t:alg_socket { getattr getopt ioctl read setopt write };
allow devicekit_disk_t domain:alg_socket getattr;
allow lvm_t lvm_t:alg_socket { append bind connect create getattr getopt ioctl read setattr setopt shutdown write };
allow sosreport_t domain:alg_socket getattr;
allow sysadm_t domain:alg_socket getattr;
allow unconfined_domain_type domain:alg_socket { accept append bind connect create getattr getopt ioctl listen lock map name_bind read recvfrom relabelfrom relabelto sendto setattr setopt shutdown write };

The above is the same as on the Trixie release policy as these things aren't changed often. Below is from Debian/Bookworm which is the same apart from Bookworm not allowing lvm_t:

$ sesearch -A -c alg_socket /tmp/policy.33
allow NetworkManager_t NetworkManager_t:alg_socket { accept bind create read setopt write };
allow bluetooth_t bluetooth_t:alg_socket { accept append bind connect create getattr getopt ioctl listen read setattr setopt shutdown write };
allow daemon init_t:alg_socket { getattr getopt ioctl read setopt write };
allow devicekit_disk_t domain:alg_socket getattr;
allow sosreport_t domain:alg_socket getattr;
allow sysadm_t domain:alg_socket getattr;
allow unconfined_domain_type domain:alg_socket { accept append bind connect create getattr getopt ioctl listen lock map name_bind read recvfrom relabelfrom relabelto sendto setattr setopt shutdown write };

I checked every Debian policy back to when the alg_socket class was first added and found that the older versions had fewer domains granted access. The most recently added was bluetooth_t and the one before that was NetworkManager_t.

The Risky Lines

Of those allow statements the following are the risks:

Unconfined Domains and the unconfined_domain_type Attribute

When writing policy lines like the following line aren't generally considered a problem as unconfined domains are allowed full access to the system. However it can be an issue if you have a process in an unconfined domain without root access, which means a regular user login. Unfortunately this happens to be where this exploit and the default Debian SE Linux configuration intersect.

allow unconfined_domain_type domain:alg_socket { accept append bind connect create getattr getopt ioctl listen lock map name_bind read recvfrom relabelfrom relabelto sendto setattr setopt shutdown write };

The following shell code gets a list of unconfined domains which can be entered from user domains.

A=""
for n in $(seinfo -x -a unconfined_domain_type|grep _t$) ; do
  A="$A|($n)"
done
A=$(echo $A|sed -e s/^.//)
sesearch -T -s user_application_exec_domain -c process|egrep "$A;"

Below is the output on a Debian/Trixie (Stable) system. So a confined user in the user_t domain could run an X server and try and get it to run the exploit code (which seems difficult) or running a Wine or Mono program from the Window manager in a Wayland environment.

type_transition user_t xserver_exec_t:process xserver_t;
type_transition user_wm_t mono_exec_t:process mono_t;
type_transition user_wm_t wine_exec_t:process wine_t;
type_transition user_wm_t xserver_exec_t:process xserver_t;

The issue of unconfined domains in SE Linux policy needs much more work. I'll write some blog posts about it later and the next release of Debian will be significantly better in this regard.

Daemons that Have Access

allow NetworkManager_t NetworkManager_t:alg_socket { accept bind create read setopt write };
allow bluetooth_t bluetooth_t:alg_socket { accept append bind connect create getattr getopt ioctl listen read setattr setopt shutdown write };

Network Manager is something that can potentially be exploited by a desktop user as it has a large attack surface for the desktop interface. But as the vast majority of desktop user accounts are unconfined that's not an issue. This might be an issue for some restricted desktop PCs, maybe kiosk systems and those PCs that were being installed in prisons.

The bluetooth_t domain is used by the bluetooth daemon that runs as root. While we generally are less concerned about a root process being exploited the daemon will handle some data from hostile sources and it could be used as an escalation attack by someone with a hostile Bluetooth device.

These can't be exploited without another bug.

The Lines that Aren't Problems

The getattr Lines

allow devicekit_disk_t domain:alg_socket getattr;
allow sosreport_t domain:alg_socket getattr;
allow sysadm_t domain:alg_socket getattr;

The above getattr access isn't an issue as it just allows seeing process information, and it's also by privileged domains.

The init_t Sockets

allow daemon init_t:alg_socket { getattr getopt ioctl read setopt write };

The daemon access to sockets inherited from init_t probably isn't a great idea, it's from the following section in init.te which is to allow socket activation for daemons, the comment is concerning in this context. Also socket_class_set is overly broad as without even inspecting the systemd source code I'm pretty sure that far fewer than 1/3 of the 55 classes allowed by that rule are actually supported in systemd.

ifdef(`init_systemd',`
        # Until systemd is fixed
        allow daemon init_t:socket_class_set { getattr getopt ioctl read setopt write };

But that's not really a problem as systemd has to just not create a socket of that type, if a hostile party can make systemd create such sockets then you have probably already lost.

SE Linux Protection

Overall SE Linux systems running confined users (kiosks and other confined GUI environments) will be protected barring a bug in Network Manager or the Bluetooth daemon as long as there is no Xserver installed (or the X server won't run scripts on startup), no Wine system installed, and no Mono.

SE Linux servers and VMs will be protected against daemon issues as long as the daemon isn't unconfined.

To convert the default login to user_t run the following commands:

semanage login -m -s user_u -r s0 __default__
restorecon -R -v -F /home

But it is still possible to access an unconfined domain from user_t (a topic I will address in detail in a future blog post).

To remove unconfined entirely (not a task for novices or something to be done on in production without testing and planning) run the following commands:

semanage login -m -s root -r s0 root
# logout and login again
semodule -X 100 -r unconfined

Then a Debian/Trixie system running SE Linux will be safe against this attack even when running a vulnerable kernel.

If you still want to use root as unconfined_t but still have untrusted shell users then run the following command to remove the easiest ways for users to run a program in an unconfined domain:

semodule -X 100 -r mono wine

Success and Failure

Blocked by SE Linux

Below is what happens on stdout/stderr when SE Linux blocks the exploit (tested with vulnerable Debian kernel 6.12.74+deb13+1-amd64):

test@testing1:~$ python3 ./copy_fail_exp.py 
Traceback (most recent call last):
  File "/home/test/./copy_fail_exp.py", line 9, in <module>
    while i<len(e):c(f,i,e[i:i+4]);i+=4
                   ~^^^^^^^^^^^^^^
  File "/home/test/./copy_fail_exp.py", line 5, in c
    a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'*64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"*4+c],[(h,3,i*4),(h,2,b'\x10'+i*19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o)
  File "/usr/lib/python3.13/socket.py", line 233, in __init__
    _socket.socket.__init__(self, family, type, proto, fileno)
    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^PermissionError: [Errno 13] Permission denied
test@testing1:~$ su
Password:

When the attack is blocked by SE Linux there will be no messages in the kernel message log but the SE Linux audit log (typically stored in /var/log/audit/audit.log) will have lines like the following:

type=AVC msg=audit(1777803068.070:76): avc:  denied  { create } for  pid=811 comm="python3" scontext=user_u:user_r:user_t:s0 tcontext=user_u:user_r:user_t:s0 tclass=alg_socket permissive=0
type=SYSCALL msg=audit(1777803068.070:76): arch=c000003e syscall=41 success=no exit=-13 a0=26 a1=80005 a2=0 a3=0 items=0 ppid=791 pid=811 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="python3" exe="/usr/bin/python3.13" subj=user_u:user_r:user_t:s0 key=(null)ARCH=x86_64 SYSCALL=socket AUID="test" UID="test" GID="test" EUID="test" SUID="test" FSUID="test" EGID="test" SGID="test" FSGID="test"
type=PROCTITLE msg=audit(1777803068.070:76): proctitle=707974686F6E33002E2F636F70795F6661696C5F6578702E7079

For that the :76 is the audit log entry number, the command "ausearch -i -a 76" will interpret that message with the following output:

type=PROCTITLE msg=audit(05/03/26 10:11:08.070:76) : proctitle=python3 ./copy_fail_exp.py 
type=SYSCALL msg=audit(05/03/26 10:11:08.070:76) : arch=x86_64 syscall=socket success=no exit=EACCES(Permission denied) a0=alg a1=SOCK_SEQPACKET a2=ip a3=0x0 items=0 ppid=791 pid=811 auid=test uid=test gid=test euid=test suid=test fsuid=test egid=test sgid=test fsgid=test tty=pts0 ses=1 comm=python3 exe=/usr/bin/python3.13 subj=user_u:user_r:user_t:s0 key=(null) 
type=AVC msg=audit(05/03/26 10:11:08.070:76) : avc:  denied  { create } for  pid=811 comm=python3 scontext=user_u:user_r:user_t:s0 tcontext=user_u:user_r:user_t:s0 tclass=alg_socket permissive=0 

When it Works

Below is what happens when it works (again tested with Debian kernel 6.12.74+deb13+1-amd64):

test@testing1:~$ python3 ./copy_fail_exp.py 
# 

Here is the kernel log when the attack works:

[   30.441830] alg: No test for authencesn(hmac(sha256),cbc(aes)) (authencesn(hmac(sha256-avx2),cbc-aes-aesni))
[   30.447466] process 'su' launched '/bin/sh' with NULL argv: empty string added

When the Kernel Isn't Vulnerable

If the kernel isn't vulnerable and SE Linux permits the attack (EG run from an unconfined domain) the following is seen on stdout/stderr:

$ python3 ./copy_fail_exp.py 
Password: 
su: Authentication failure

In that situation the kernel will log something like the following:

[   36.647023] alg: No test for authencesn(hmac(sha256),cbc(aes)) (authencesn(hmac-sha256-lib,cbc-aes-aesni))

This was tested on the Debian/Unstable kernel 6.19.13+deb14-amd64.

Conclusion

Run the following commands and then force all users to logout to make a Debian SE Linux system offering shell access reasonably safe against this bug. But also upgrade your kernel as soon as convenient because having multiple layers of protection is always good.

semanage login -m -s user_u -r s0 __default__
restorecon -R -v -F /home
semodule -X 100 -r mono wine

The GrapheneOS people are doing really good work on securing phones, I am most interested in Mobian (Debian on phones) but for people who have made different choices GrapheneOS is a good option. Here is the GrapheneOS statement on Copy Fail (they are not vulnerable to it) [3]. For people interested in running a secure Android build GrapheneOS is the best option. Their supported devices list shows Pixel 6 to Pixel 10 supported and Pixel 8 to Pixel 10a recommended [4]. In Australia Kogan sells refurbished Pixel 6 phones starting at $251 including delivery and refurbished Pixel 8 phones starting at $499 with "First" membership, they seem to have the cheapest Pixel phones.

I want to make Debian more like Android in terms of security, but that's a topic for other blog posts.

Here is the Debian page listing kernels that have been fixed against this exploit [5].

• [1] https://tinyurl.com/224mdjxn
• [2] https://wiki.archlinux.org/title/Kernel_mode_setting
• [3] https://tinyurl.com/2cp5gtyr
• [4] https://grapheneos.org/faq#supported-devices
• [5] https://tinyurl.com/25ghcmzp

04 May 2026 8:00am GMT

Review: Full Speed to a Crash Landing, by Beth Revis

Series:	Chaotic Orbits #1
Publisher:	DAW
Copyright:	August 2024
ISBN:	0-7564-1947-6
Format:	Kindle
Pages:	153

Full Speed to a Crash Landing is a science fiction novella and the first of a series. Beth Revis made the New York Times bestseller list for an earlier series of young adult science fiction novels, but somehow I had not heard of her before this series.

Ada Lamarr is a salvager. She picks up material from crashed or dead ships for resale. As the story opens, she has a large hole in the side of her ship, she's running out of oxygen, and the other ship nearby is refusing to answer her distress call. By the time they finally respond, there is barely enough time to get aboard before she is entirely out of air.

Ada's first-person narration drops hints that she may not be entirely what she seems. But then, neither is the Halifax, so it's only fair.

The captain of the Halifax treats Ada with a great deal of suspicion and wants her out of the way of their ongoing salvage operation. However, the captain does not appear to be entirely in charge. Ada is immediately struck by the mysterious Rian White, who seems to have some authority over their mission and is more thoughtful and calculating than the rest of the crew. He's also handsome, which doesn't hurt.

I was tempted to keep writing about the plot, but given the short length of this book, I should stop there and let you enjoy the twists and turns for yourself. This is a fun science fiction action romp: lots of banter, lots of tense moments, and a cagey first-person protagonist with an irrepressible sense of humor and a knack for brazening her way through conversations. It's not long on world-building (there isn't enough room), but Revis works in enough details to be intriguing and to set up some interesting motivations.

This is the sort of book that lives and dies by how much you like the protagonist, something that you will easily figure out by the end of an ebook sample if you're the sort of reader who uses those. Ada is irreverent, talkative, and very adroit at diverting attention (entertainingly) onto anything other than the critical piece of information other people are missing. If you want to, I suspect you could easily figure out most of what Ada is up to before the book reveals it explicitly. It's not that complicated, and the book isn't really trying to hide, although it doesn't give you all the necessary information in advance. Personally, I was happy to sit back and enjoy the ride.

There is no romance in this book beyond frequent comments from Ada that she would have liked there to be a romance in this book under different circumstances, but I will be surprised if that romance doesn't show up later in the series. Ada and Rian are clearly being set up as a pair. I didn't like Rian as much, mostly because he's less memorable as a character, but he comes into his own in the appendices after the plot proper.

I thought those concluding appendices were the best part of the novella and question the Kindle formatting decision to treat them like supplemental material. They purport to be a series of government memos, fill in a lot more of the backstory and world building, and have the best footnotes. Don't skip them!

This isn't the sort of book that I am inspired to immediately push into everyone's hands, but it's a fast, well-paced story that delivered a few reading sessions of entertainment. I'm not sure the political philosophy in the background makes a lot of sense, but at least not a standard stereotype of current politics seen in so much science fiction. It's going to set up some interesting character conflict in later books. I'm certainly intrigued enough to keep reading.

Recommended when you're in the mood for some fast-paced fun that's short and undemanding.

Followed by How to Steal a Galaxy.

Rating: 7 out of 10

04 May 2026 3:56am GMT