<clever>
jasom: this causes services.xserver.enable to spawn a vnc server, and then all of the normal login prompt and session stuff "just works" within that
<clever>
qqii: if you search nixpkgs/pkgs/top-level/python-packages.nix for youtube-dl-light, youll see that both packages share the default.nix, but one has an override on 2 params
<clever>
qqii: one depends on ffmpeg, the other doesnt
<clever>
qqii: nix-diff $(nix-instantiate '<nixpkgs>' -A youtube-dl-light) $(nix-instantiate '<nixpkgs>' -A youtube-dl)
<clever>
you just need to keep track of what each slot is for, so you know which one to delete later
<clever>
that allows having a backup password, so you can still open it if you loose the keyfile, and then you can re-add a new keyfile
<clever>
snow: this reveals that there are 8 slots on my system, and only slot 0 is currently in use
<clever>
or just `nix-store -r /nix/store/foo` to download it from a configured binary cache
<clever>
makefu: if you use nix-copy-closure (and have nix on the legacy machine), those hard-coded paths will exist
<clever>
makefu: which will just copy the cfg, and assert that its valid
<clever>
makefu: only thing missing, is to add named-checkconf into the mix, replace the ${cfg.configFile} on 195, with the result of `runCommand "named.conf-checked" { buildInputs = [ bind ]; } ''cp ${cfg.configFile} $out ; named-checkconf $out''`
<clever>
and 28/29 tells it to use that dir
<clever>
191 will also ensure `named` owns the state dir
<clever>
shouldnt care what the uid is
<clever>
line 187 and 195 will tell bind to lookup `named` in `/etc/passwd` at runtime, and drop-root at the right times
<clever>
bind creates a user called `named` and thats the only real problem i can forsee
<clever>
ahhhh, and you can have multiple "pci data structures" in a single rom, each with its own "code type"!
<clever>
ah, 2 systems, the old one with just a raw x86 entrypoint, and then a new one with a table that describes all the capabilties and entry point type
<clever>
i'm guessing if you want to support 2 options, you need 2 roms, and spend 2 BAR's on it?
<clever>
and further down, you have the code type, x86, open firmware, efi, ...
<clever>
and expects the function to return control back to the bios, eventually
<clever>
the bios will just call whatever function happens to be there, on bootup
<clever>
Miyu-chan: offset 03h is the main one, `Entry point for INIT function. Power-On Self-Test (POST)does a FAR CALL to this location`
<clever>
but the other lists it as a 16 bit field, of aa55
<clever>
one site lists it as 0x55 0xaa, which i assumed was 55aa
<clever>
Miyu-chan: but modern systems, have pxe booting built into the bios, and the NIC's that do have "roms" tend to have flash memory, which is where https://ipxe.org/howto/romburning comes in
<clever>
Miyu-chan: in the old days, you could program a rom, shove it into a socket on your NIC, and then configure the bios to network boot, and it will just run whatever is on the rom
<clever>
Miyu-chan: network cards are also special
<clever>
Miyu-chan: you may now read the horror stories above :P
<clever>
the only way to be 100% sure, is to either prevent reflashing entirely, or to flash it externally, so the untrusted code is never ran
<clever>
levdub: which then lies about having reflashed the hardware
<clever>
levdub: the problem, is that if the reflashing happens by just booting the machine into a special os, it could be booting that inside a hypervisor
<clever>
but if you can reflash the bios, its game over
<clever>
the whole point of secureboot, is to ensure only signed blobs of code are loaded while booting, so you can trust the login prompt when it asks for a pw
<clever>
Miyu-chan: and thats part of what secureboot wants to stop you from doing (which also blocks your ability to just run your own firmware)
<clever>
Miyu-chan: but if you get root on a machine that supports flashrom, you could malware the bios itself
<clever>
sadly, ive only found 1 machine where flashrom has write support, and 2 or 3 with read-only support
<clever>
in the case of my router, its only 1mb
<clever>
-rw-r--r-- 1 root root 1.0M Jun 28 04:55 router.bios
<clever>
Miyu-chan: this will read the entire bios, and dump it to a file
<clever>
Devices may have an on-board ROM containing executable code for x86 or PA-RISC processors, an Open Firmware driver, or an EFI driver. These are typically necessary for devices used during system startup, before device drivers are loaded by the operating system.
<clever>
the bios will just blindly run a blob it finds in a pci-e device, if the fields are set right
<clever>
yes
<clever>
raid controllers often use that to show a "press f7 to configure raid" menu
<clever>
video cards use that to initialized themselves
<clever>
Miyu-chan: and on the subject of vBIOS stuff you mentioned, pcie devices can include a firmware blob, and the specs from legacy bios will just blindly run that firmware on bootup
<clever>
so you dont get any weird numa problems, like core1 asked for data, then core2 got the reply, and they have to sync their L1 caches up via ram
<clever>
which goes back to the core that initiated the request
<clever>
and each fifo has its own IRQ to signal when its finished
<clever>
each core, has its own fifo to issue read/write requests
<clever>
this is because pcie supports multiple command queues
<clever>
and never has a given irq hit more then 1 core
<clever>
in this gist, youll notice my nvme device, has 8 IRQ's, and is firing requests off to all my cores!
<clever>
Miyu-chan: thats something entirely different, and not really in the scope of iommu
<clever>
so the cpu will enforce what each card can do
<clever>
but there is iommu, where you can configure a memory mapping on a per-slot basis
<clever>
Miyu-chan: the typical CPU will just blindly obey the attack
<clever>
so the pcie device must ask the cpu to fetch something from ram (but it still bypasses the opcode execution system)
<clever>
but in modern pcie, all pcie devices are wired directly to the cpu
<clever>
reversing the master/slave setup
<clever>
Miyu-chan: in the legacy pci days, bus master means the pci device could drive the addr lines on its own, and directly read ram without having to involve the cpu
<clever>
Miyu-chan: and i havent even touched on DMA yet :P
<clever>
but when you have 16g of video ram, and only a 256mb window into it, there must be some mapping going on, and you must understand that, or it will screw you over
<clever>
to learn which regions i shouldnt touch :P
<clever>
i also had fun just dd'ing to different offsets, and watching the screen to see what corrupted what
<clever>
i used lspci to find the phys addr, and then configured MTD to just treat that region as a block device
<clever>
ive done exactly that, back when my entire gpu ram fit within a single BAR
<clever>
and it has such a large chunk of the address space, so you can copy a large chunk at once
<clever>
and then just use a dumb memcpy to upload textures
<clever>
i highly suspect there is memory mapping going on, so you can configure the gpu to map portions of that 256mb window, to portions of the gpu ram
<clever>
Miyu-chan: my GPU, has a whole 256mb chunk of the address space (but i think it has 16g of gpu ram)
<clever>
Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M]
<clever>
Shados: yeah, thats what i was guessing
<clever>
my sound card has 16kb of "ram" and no "io"
<clever>
yeah, io ports still exist, lol
<clever>
next usb device only has 256 bytes of "ram"
<clever>
the 1st usb controller i see, only has 4kb of "ram" and no "io" at all (likely all memory mapped io)
<clever>
the IO use the special in/out opcodes in the cpu, while the "ram" is just a normal physical address you can read/write from
<clever>
my 1st sata controller has 6 regions, 5 of them are IO (of varying sizes) and one is 1024 bytes of "ram"
<clever>
depends on the device
<clever>
i believe those are the BAR's
<clever>
look for the `Region 0: ` parts
<clever>
[root@amd-nixos:~]# lspci -vv
<clever>
looks like your right
<clever>
`program the Base Address Registers (commonly called BARs) to inform`
<clever>
ive even been crazy enough to write my own opengl driver, from scratch, right down to probing the IO ports in the 3d core :P
<clever>
and yeah, i have read a lot of the docs on the 3d side of things, but the firmware is still closed on the rpi, and the hw video decode stuff is fully closed, so i wonder what else there is, that could possibly compete
<clever>
in the rpi4 announcement, they mentioned they are sticking to videocore4 (the 3d core) because its the "most open" in the arm market
<clever>
samueldr: i was told that the PD_SENSE pin is wired up, to signal to the charger what its demands are
<clever>
the new 4 model
<clever>
the rpi has usb 3.0, proper gigabit ethernet, usb-c power/gadget, and with some uber-hacking, you could maybe get pci-e out of it
<clever>
lordcirth_: the rpi4 cpu is also a better design, that can do more work for a given clock rate
<clever>
lordcirth_: i may have even heard of rumors of LN2 cooling
<clever>
lordcirth_: many
<clever>
and then i need to convince the x86 gdb to open a core dump from arm
<clever>
it was an emulated segfault, within the x86 side, but i think it produced an arm core file
<clever>
so it was imposible to debug
<clever>
and gdb was heavily confused by the arch mix
<clever>
lordcirth_: i was trying to run teamspeak, but it segfaulted within pulseaudio
<clever>
ive also done silly things like emulate x86 on an rpi
<clever>
but it happens to support emulating the host arch with zero trouble, lol
<clever>
because its meant to be used for foreign arches
<clever>
yeah, qemu-user always lacks hw accel
<clever>
which simulated the lack of sse4
<clever>
but, i then switched to using qemu-user-x86_64, to emulate 64bit (in userland) on 64bit, lol
<clever>
because qemu by default emulates the oldest 64bit capable cpu (which lacks sse4)
<clever>
i was initially using qemu-system to debug the sse4 problem
<clever>
ive discovered sse4 features in some stuff iohk ships
<clever>
yeah
<clever>
openssl (at least years ago) produced a poisoned build, like python does now
<clever>
kexec-tools also has the same issue, but correctly fails, rather then producing poisoned builds