channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev2&y=22&m=5&d=10
00:00:00 <heat> and erm, thinking about it again, that doesn't really matter
00:00:00 <heat> clac is supposed to protect against accidental writes
00:00:00 <geist> exactly
00:00:00 <heat> i really should look at doing that xD
00:00:00 <geist> 64bit syscall entry you dont have to clac because you can put it in the mask bits of the STAR register
00:00:00 <geist> so that it comes automatically cleared
00:01:00 <geist> but i dont think you get that with 32bit syscall
00:01:00 <geist> and sysenter, dunno.
00:20:00 <geist> anyway the itanium mechanism is whacky: you can mark a page (or any number of them) as syscall trampoline pages. i forget what the name is
00:20:00 <geist> but basically it's a bit on the page
00:20:00 <geist> and then if the cpu is in user mode and inside the page and it runs the 'epc' instruction, it just switches to ring0 and continues running
00:21:00 <geist> so basically you build your vdso out of that to then just direct branch up to the kernel
00:21:00 <geist> so it seems impossible to do that securely but i think the trick is the fact that ia64 has the bundled instructions (up to 3 instructions in a bundle) and you can't partially run a bundle, or branch into the middle of them
00:22:00 <geist> so you carefully arrange for it to be that if you branch to any spot before or after the bundle with the epc in it it is detected that it happened
00:22:00 <geist> otherwise the instruction is basically zero cost transition from ring 3 to ring0
00:23:00 <heat> how does it detect that?
00:24:00 <geist> detect what?
00:25:00 <heat> that you branched before or after the epc
00:25:00 <geist> cpu doesn't, software does
00:25:00 <geist> now maybe that linux url you linked before will make more sense
00:25:00 <geist> because it's talking about the kernel side of it, and i thik there's some implicit structure to it
00:26:00 <geist> (it still doesn't, but that's the fun brain teaser about it)
00:27:00 <geist> it may also be set up such that it's not really important that every possible branch point be validated and rejected, but more that it'll just crash the program if you dont
00:27:00 <heat> “alloc” instruction
00:27:00 <heat> oh jeez oh man
00:27:00 <heat> ia64 assembly D:
00:27:00 <geist> for exampe if you branched after the epc instruction you'd just get a branch up to the kernel, well that'll fail because it didn't make it into ring 0
00:28:00 <geist> or if you skipped over the part where it lodas the syscall # into the right register, doesnt matter, you'l get out out of bound syscall, etc
00:28:00 <geist> it's only important that you cant defeat the mechanism and somehow get a sploit
00:31:00 <heat> yup
00:31:00 <heat> this vdso problem is brain teasing the shit out of me
00:32:00 <heat> i was thinking that "mandatory vdso" could make it a security boundary, but I guess that's not really possible in current architectures
00:34:00 <heat> you could write into vdso .text :D
00:35:00 <heat> vdso_entry: mov $0x90, syscallret; syscall; syscallret: mov $0xCC, syscallret; ret
00:36:00 <heat> but then everyone can write to vdso text, so that doesn't work as well lol
00:36:00 <heat> and serialization would be an issue
00:36:00 <heat> and cache flushing too
00:51:00 <mrvn> AmigaOS has something similar to the EPC thing. When you enter supervisor mode it checks if the return address is the library function that should do super visor switches and if not it's a violation.
00:54:00 <mrvn> heat: what would stop anyone from jumpting to vdso_entry+7?
00:55:00 <heat> what's +7 here?
00:57:00 <mrvn> syscall
01:01:00 <heat> it would go int3 and die
01:06:00 <mrvn> What do you get when you cross an elephant with a rino? Hell-if-I-know.
01:08:00 <Mutabah> I guess such a check is just defence-in-depth
01:09:00 <Mutabah> sure a mailcious program could jump to the `syscall` instruction, but it'd be one more step in a chain
01:16:00 <geist> interesting: the gcc 12.x zero length array thing
01:16:00 <geist> looks ike it only applies to pointers < 4K (0x1000)
01:16:00 <geist> https://gcc.godbolt.org/z/zxodK7q6s
01:16:00 <geist> the first read fails, secod one succeeds
01:17:00 <geist> this is maybe why most folks dont see it. it's guessing that anything within first 4K is really a null pointer
01:18:00 <geist> i was seeing it explicitly because the firmware on the 68k board leaves a data structure at 0x400 that i was reading some bits out of
01:21:00 <geist> so *thatS* probably wy the linux kernel still builds with this (presumably)
01:21:00 <geist> it's more so than just dereffing a raw pointer
01:21:00 <mrvn> Yeah, it's a odd little thing that everything below 0x400 is kernel mode only.
01:21:00 <mrvn> writable
01:25:00 <geist> well nothing a #pragma can't solve
01:25:00 <geist> ie, https://gcc.godbolt.org/z/qrGxP1Wz1
01:26:00 <mrvn> would be nicer if one could attach that to the pointer itself.
01:28:00 <mrvn> https://gcc.godbolt.org/z/94zvnjjf7
01:28:00 <mrvn> why isn't clang using #-1[r1] to load r0?
01:30:00 <geist> dunno, my experience is compilers are generally not really good at constant folding like that
01:30:00 <geist> or sharing of nearby constants at least
01:31:00 <mrvn> I've seen this with UART code too. Even if you make a pointer to the UART base and then access p[0], p[4], p[20] it till compute the absolute addresses of each and load each from memory into a register.
01:31:00 <mrvn> s/till/will/
01:32:00 <geist> i think i've pointed it out every time this comes up but i've seen a compiler (TI piccolo DSP) that actually as a post link optional constant folding pass
01:32:00 <geist> basically looks at the binary and then tries to restructure the code to combine stuff like this
01:32:00 <mrvn> I would be happy if gcc stopped unfolding constants
01:32:00 <geist> and definitely fold constant pools together
01:33:00 <geist> but then try to modify existing code to base off less common constants. pretty neat idea
01:33:00 <geist> might not really be adding or removing instructions though, but on a little arch like Piccolo it might use load + PC to get constants a lot, and combining those post link would be fairly easy
01:34:00 <mrvn> On ARM *0xfff should also do 0x1000-1 on its own. There is no need to create the exact constant, only something close enough to access with an offset.
01:40:00 <clever> something ive kind of wanted (having seen it in a lot of asm i look at), is if i have a whole whack of 32bit constants (peripheral reg addrs) being cast into pointers and de-referenced
01:40:00 <clever> for the compiler to find a common base, store that in a reg, and then do reg+immediate addressing
01:41:00 <mrvn> or just leave the common base I typed in
01:41:00 <geist> mrvn: i do forget what the range of offsets are for ldrs, they might be units of 4, and/or not negative
01:41:00 <geist> but the idea still stands
01:41:00 <clever> some of my newer code is doing constant + constant + constant to create those reg addr's
01:42:00 <clever> and instead of pre-adding them at compile time, it could shove one into a reg, and add at runtime
01:42:00 <mrvn> they usualy are in multiples of the data type. No point providing unaligned access
01:42:00 <mrvn> clever: except the compiler sees the pointer is a literal and then optimizes the variable away
01:43:00 <clever> yeah, it needs to detect when a dozen literals are within range of a reg+immediate load, and are all being used for load/store
01:44:00 <mrvn> that and when a constant is used multiple times and keep it as a base
01:45:00 <clever> https://github.com/librerpi/lk-overlay/blob/master/platform/bcm28xx/hvs/include/platform/bcm28xx/hvs.h#L9-L18
01:45:00 <bslsk05> github.com: lk-overlay/hvs.h at master · librerpi/lk-overlay · GitHub
01:45:00 <clever> an example of adding 3 constants
01:46:00 <clever> if i was writing the asm directly, i might use SCALER_BASE in a reg, and then reg+imm offsets
01:46:00 <geist> that being said theres probably some particular optimization paths on particular cores of particular arches where it's better to start from scratch on very pointer
01:46:00 <clever> but because of the lack of clean tools for computing those offsets, i do this instead:
01:46:00 <geist> i can see, for example, x86 chewing up movabs + mov
01:46:00 <geist> like that's probably flattened into a single uop
01:46:00 <clever> https://github.com/librerpi/lk-overlay/blob/master/arch/vpu/start.S#L59
01:46:00 <bslsk05> github.com: lk-overlay/start.S at master · librerpi/lk-overlay · GitHub
01:47:00 <geist> and not doing a offset addition can probably save one uop or whatnot
01:47:00 <clever> where i just have a bit flat list of reg+value's and i load each pair, and store
01:47:00 <geist> or use more execution ports
01:47:00 <clever> yeah, speed is also a question
01:48:00 <clever> which is faster, a giant table of immediates that you need to ldr, or a reg+offset
01:48:00 <geist> ARM cores i thik all have basically 'free' offset additions, but writeback usually adds a cycle or so of latency
01:48:00 <clever> writeback?
01:48:00 <geist> so if you have a long list of dependent loads, like pushing/popping off a stack it's generally recommended to decrement/increment and then do load/stores relative to that
01:49:00 <geist> `ldr x0, [x1], #4!` kinda stuff
01:49:00 <clever> ah, yeah, if your changing sp a lot
01:49:00 <geist> basically post or preincrement with write back to the base register
01:49:00 <clever> then it needs to know the new sp
01:49:00 <mrvn> I believe the imm in "ldr x0, [x1], #4" is free.
01:49:00 <geist> most high end cores have a completely special path for SP though, but in general for other regs may not
01:49:00 <clever> most asm i see, just does an add/sub to sp, then sp-relative load/store
01:50:00 <geist> mrvn: i think it might add another cycle of latency for the writeback, but then compared to a single add afterwards it's still better
01:50:00 <mrvn> same with (%eax, %edx * 4, #16) on x86
01:50:00 <geist> *unless* you have another ldr right after it, in which case you're adding a bubble
01:50:00 <mrvn> might be
01:50:00 <mrvn> but is loading a constant from memory faster?
01:51:00 <geist> that's what i mean, they say if you have a long series of load/stores that fiddle with the same base register, usually better to modify the base register before or after
01:51:00 <geist> and then use the 'free' offset addition that comes with the load/store unit
01:51:00 <geist> i'm thinkig mostly stuff like pushing/popping from the stack or some data structure manipulation
01:52:00 <geist> reading 4 things out of the array and then bumping the pointer by 4
01:52:00 <mrvn> stack is different though as it's nearly always in cache
01:52:00 <geist> wel more so than that, the SP has special machinery behind it potentially to keep it very close to earlier stages in the pipeline
01:52:00 <geist> arm64 codifies that by making SP be outside the regular register file
01:53:00 <geist> it can basically sit off by tself and get known earlier in the pipeline, and only needs to be flushed back to the register file on some sort of instruction that needs the value
01:53:00 <mrvn> stack access might even just work out of the write buffer, so even closer than L1 cache
01:53:00 <geist> yah
01:54:00 <geist> i forget precisely how ARM64 encodes the SP. dunno if it has its own opcodes (you can only do some ops against SP) and/or if it's encoded as x31 (zero register) when a base register to LDR/STR
01:55:00 <vdamewood> I think it only had load and store with the regular file
01:55:00 <mrvn> using x31 in LDR/STR seems kind of unwanted so I would assume that gets overloaded to something else.
01:55:00 <vdamewood> Oh, wait. it would make sense for it to also support add and sub operations
01:55:00 <geist> you can use it as a base and whatnot in arm64 at least, and even load into it, but it must be encoded differently
01:56:00 <geist> yah you can do add/sub with oit, but most of the bit operations aren't supported
01:56:00 <geist> mrvn: yeah. how it's encoded as a target register i dunno, becuase you absolutely can load/store xzr
01:56:00 <vdamewood> Whcih makes sense, you rarely want to bitshift your stack pointer.
01:57:00 <mrvn> vdamewood: linux used to have the struct TASK at the top of the stack so you would do: (SP + 0x7FFF) & ~0x7FFFF to access it.
01:57:00 <mrvn> or SP >> N << N
01:58:00 <mrvn> when stack goes upwards
02:03:00 <geist> okay. just verified. you can use SP in the base register slot of any load/store, and it seems to use x31 encoding for that
02:03:00 <geist> but you cannot load/store into/out of SP. thought you coudl, but no
02:03:00 <geist> so that makes sense. if you want to save SP to the stack you need to move it into another register, which is usually what happens anyway. save x30 (the base register) and then load SP -> x30
02:05:00 <mrvn> -fomit-stack-pointer
02:06:00 <geist> and looks like the ALU ops that work against SP are a special opcode that explicitly is for 'extended registers'
02:06:00 <geist> and only has a few opcodes like add/subtract
02:06:00 <geist> and in that case it's the same thing: x31 is SP. presumabky you can't do things with xzr in those instructions
02:06:00 <geist> like maybe add sp, sp, xzr is illegal
02:07:00 <mrvn> makes sense, most ops with 0 with ned NOPs. "0 - reg" usualy has it's own opcode
02:12:00 <oriansj> hello, I have a strange question but in the interest of creating the next major piece in https://bootstrappable.org/ I need to write a POSIX kernel in assembly (or find an already existing one) capable of running TCC (or GCC) and I was wondering if anyone had or knew of a kernel they would be willing to let me leverage for that work?
02:12:00 <bslsk05> bootstrappable.org: Bootstrappable builds
02:13:00 <mrvn> linux works fine to run gcc
02:13:00 <oriansj> mrvn: a bit hard to hand convert to assembly though
02:14:00 <mrvn> I don't know, gcc does that fine. :)
02:14:00 <oriansj> mrvn: I know, we bootstrapped GCC from hex
02:15:00 <oriansj> but to address the Ken Thompson Trusting trust attack, it requires us to create a trusted bootstrap and as of yet we haven't bootstrapped GCC on bare metal yet
02:16:00 <oriansj> we have bootstrapped a much simpler C compiler on bare metal but it likely is not going to be powerful enough to get us to GCC without considerable more effort.
02:17:00 <oriansj> and we do have a path from hex to Linux+GCC+Guile https://github.com/fosslinux/live-bootstrap without only the kernel being the problem
02:17:00 <bslsk05> fosslinux/live-bootstrap - Use of a Linux initramfs to fully automate the bootstrapping process (11 forks/151 stargazers)
02:19:00 <Mutabah> Depending on your hardware target, a posix-ish kernel (enough to run tcc) wouldn't be too complex - you'd probably want something purpose built though.
02:19:00 <Mutabah> That said, I think most bootstrapping projects go via an intermediate language - e.g. forth
02:20:00 <mrvn> Maybe just build a barebone gcc?
02:20:00 <mrvn> gcc doesn't need a lot of syscall
02:20:00 <Griwes> I mean supposedly you have a C compiler in assembly already, so you could write a simple kernel in C, which would be an improvement over needing to do it in assembly
02:21:00 <oriansj> Griwes: yes we wrote a C compiler in assembly that does run on bare metal and one that was written in assembly to run on a POSIX kernel using only open/close/read/write/brk
02:23:00 <Griwes> also I hope you aren't targeting x86, because both microcode and smm can work around any bootstrapping mitigations to the thing Thompson described :P
02:23:00 <Mutabah> ^
02:24:00 <Mutabah> I'd probably target a RV64 board, with some form of basic onboard flash storage
02:24:00 <clever> Griwes: i assume it would have rules about picking a cpu or firmware that is also trustable, but building that...
02:24:00 <oriansj> Griwes: actually we are doing ports for EVERY architecture. and have written these compilers in assembly for AArch64, armv7l, RISC-V (both 32 and 64bit), Knight, x86 and AMD64 architectures
02:25:00 <Mutabah> RV64, simple NAND flash, a basic keyboard
02:25:00 <clever> oriansj: would you be interested in adding another, that currently even lacks linux support?
02:25:00 <Griwes> right, but what I'm saying is that x86 is particularly untrustworthy if you're caring about this
02:26:00 <oriansj> clever: I am happy in adding *EVERY* possible CPU architecture as potential roots for bootstrapping
02:26:00 <clever> oriansj: i'm thinking about the VPU core on the rpi, that runs before the arm, and is basically a threat vector if you where to try and bootstrap using an rpi
02:26:00 <geist> what do you mean roots for bootstrapping?
02:26:00 <clever> oriansj: but if you instead bootstrap from the VPU, it cant be a threat
02:26:00 <Mutabah> I think Griwes' point is that if you're going to the level of writing a kernel for bootstrapping, you also want to be aware of the issues of your hardware
02:27:00 <Mutabah> x86 would be fine... with much older x86 chips that don't have microcode.
02:27:00 <geist> i'm missing the point here, what is going on?
02:27:00 <oriansj> geist: as in all of the architectures bootstrap to a universal cross-platform build toolset which enable any architecture to audit the results of all other architectures creating a mesh of audits
02:28:00 <clever> oriansj: i think the main features to be aware of on the VPU, is that the opcode size is variable (but always a multiple of 16bits), there is no mmu, but there is a form of MPU, and it can do cache-as-ram, and has a working secure mode similar to arm
02:28:00 <geist> ah okay
02:28:00 <oriansj> the key goal is I need to find a kernel to serve the purpose of providing a bootstrap Kernel for bootstrapping the entire world
02:29:00 <mrvn> have you looked at lk?
02:30:00 <oriansj> mrvn: did you mean this: https://github.com/littlekernel/lk ?
02:30:00 <bslsk05> littlekernel/lk - LK embedded kernel (521 forks/2589 stargazers/NOASSERTION)
02:30:00 <mrvn> yes
02:30:00 <oriansj> honestly never heard of it before but I am looking at it now. Can it run tcc or gcc?
02:30:00 <mrvn> ask geist
02:31:00 <clever> oriansj: i believe out of the box, it lacks a userland and modules, but there is a proof of concept userland
02:31:00 <oriansj> clever: I don't need any userland at all
02:31:00 <clever> https://github.com/littlekernel/lkuser
02:31:00 <bslsk05> littlekernel/lkuser - framework for a simple user space for lk (10 forks/18 stargazers)
02:31:00 <clever> if you bake tcc into the kernel, as just another function, it could run tcc
02:32:00 <clever> gcc feels a bit too big for that though
02:32:00 <geist> someoe is off doing a fork of that trying to get it to work too
02:33:00 <oriansj> clever: I only need the kernel to support 31 unique syscalls
02:33:00 <geist> need to build up a bunch of filesystem syscalls in the lkuser thing but could be probably hacked to get a posixy looking simple user space fairly simply
02:33:00 <klange> 31 sounds like a lot
02:38:00 <oriansj> open/close/read/write/lseek/chmod/mkdir/mknod/umask/access/chdir/unlink/getcwd brk/exec/waitpid and uname (17 core) are those that are needed to run the steps up to a cross-platform C compiler
02:39:00 <klange> mknod and uname? really?
02:40:00 <geist> yah i was curious about those too
02:41:00 <geist> maybe that's some sort of script to set up /dev first too
02:41:00 <oriansj> klange: as it currently exists right now, yes
02:42:00 <oriansj> inital file system only is expected to have 357bytes worth of binary and a pile of source code
02:42:00 <clever> dang!
02:44:00 <oriansj> so we build our init, shell, linker, assembler, C compiler, untar, ungz, sha256sum, mkdir, chmod and several other tools before we start unpacking .tar.gz files and having to make folders like /bin and /dev and more
02:44:00 <clever> sounds a lot like the nix bootstrap tools
02:44:00 <oriansj> we have a program get_machine which allows us to do host operating system directed builds
02:45:00 <oriansj> clever: it is the root of guix's bootstrap build
02:45:00 <clever> ah
02:45:00 <oriansj> we want to go deeper down the stack and remove the Kernel from the TCB
02:45:00 <clever> nix is a lot fatter, a tar containing a pre-built gcc and support binaries
02:45:00 <oriansj> but I need a kernel I *CAN* bootstrap from what we have running on bare metal
02:46:00 <oriansj> yeah, we bootstrap a full Linux distro from 357bytes
02:47:00 <oriansj> hence why I am searching for a kernel to bootstrap (either by converting to the M2-Planet C subset) or by hand compiling it into assembly
02:49:00 <oriansj> The only requirements we have is the ability to write to a storage media (ata disk/floppy disk/paper tape or something), Virtual memory, able to handle single tasking and supporting the 31 syscalls required to run TCC (no user interaction required)
02:50:00 <clever> but how can you be sure the kernel has been put together correctly, without trusting other kernels?
02:51:00 <oriansj> clever: good question
02:52:00 <oriansj> fortunately sha256sum can run on a 6502 on bare metal and monster6502 solves the lithography trust problem for us as well
02:52:00 <clever> and what about bios level exploits?
02:53:00 <oriansj> clever: well the developer for those bios level exploits is able to subvert *ALL* hardware architectures and *ALL* cross-platform builds including for CPU architectures that haven't been invented yet
02:53:00 <clever> in the case of something like the rpi, there is a ~18kb mask rom in the cpu, and some OTP to configure what it can boot from
02:53:00 <clever> and that loads up to 128kb of bootcode.bin from a configured source, into cache-as-ram
02:53:00 <clever> and then executes it
02:53:00 <clever> assuming you can trust the maskrom, would that be a possible bootstrap source?
02:55:00 <oriansj> clever: I assume all hardware is compromised but I know if we have enough hardware architectures providing roots of trust to the common perfect reproducible cross-platform builds chain; any subversion would have to work on *ALL* cpu architecture ever invented and ever to be invented *FOREVER* to avoid detection. And do so without any updates *FOREVER*
02:56:00 <clever> as far as i know, the maskrom is a true rom, and there is no mechanism available to patch it on startup
02:57:00 <clever> so if you audit the board for any unexpected flash media, you can be sure that the only code it can possibly run, is your own code
02:57:00 <clever> an attacker would have to replace the silicon in the cpu to violate those assumptions
02:57:00 <oriansj> clever: we can even throw custom hardware at the problem; like punched paper tape readers and manually inspected punched paper tape
02:58:00 <oriansj> CPUs made out of individual transistors
02:58:00 <oriansj> core memory and other exotics
02:58:00 <clever> yep
02:58:00 <clever> ive seen a computer made out of relays
02:58:00 <clever> it sounds amazing
02:58:00 <oriansj> but that will the problem *AFTER* we sort out the kernel problem
02:59:00 <oriansj> which is why I am here now
02:59:00 <clever> https://www.youtube.com/watch?v=n3wPBcmSb2U
02:59:00 <bslsk05> 'Harry Porter's Relay Computer' by hhp3 (00:02:01)
03:00:00 <oriansj> I seek a kernel to provide just enough for us to bootstrap the world; as I assume there are much better kernel programmers here
03:13:00 <oriansj> so any other kernel recommendations that I should look into as potential bootstrap kernels?
03:15:00 <klange> I think if you can manage to write all those other utilities, you can write your own kernel, and then you can trust it more because you've done a thorough source audit by writing it in the first place...
03:19:00 <Mutabah> ^
03:19:00 <Mutabah> I've not kept up with the discussion, but a few notes
03:20:00 <Mutabah> 1. if you want an assembly-only kernel, then you'll be VERY tied to the architecture
03:20:00 <oriansj> klange: well yes, doing all of that work took 5 years of effort; and if need be, I'd do the same to solve the kernel problem. But just in case someone else here is interested in that problem space and worked in that direction, I'd prefer to help them reach that shared goal
03:20:00 <Mutabah> (there is no porting, there is only re-writing)
03:20:00 <Mutabah> 2. If you don't want to write your own, then maybe look at MenuetOS?
03:24:00 <oriansj> Mutabah: well a kernel in a restrict C subset is also an option but yes you are absolutely right about assembly-only programs being very tied to the architecture
03:28:00 <Mutabah> Most pre-existing kernels will not be built with the restrictions you have in mind, so you're going to have to write your own
03:28:00 <Mutabah> does sound like an interesting project though
03:37:00 <oriansj> Mutabah: darn, I was aiming at boring and too simple to be of interest to anyone
03:38:00 <Mutabah> well, the idea of taking a simple SOC with no pre-existing firmware, and writing a basic firmware that allows data entry, and building up a bootstrapped system on a NAND chip
03:38:00 <Mutabah> although, you could probably trust a SD card to provide the data you requested?
03:38:00 <Mutabah> (you'd want some sort of signature on your data, just in case the card does mangling :D)
03:40:00 <oriansj> Mutabah: we can do sha256sum on bare hardware
03:40:00 <oriansj> also we can do custom hardware (like paper tape reader/writer made out of individual transistors)
03:45:00 <oriansj> and I do expect to have to write the same kernel for several architectures if I do it in assembly (possibly doing speed runs after the first to keep it interesting)
03:47:00 <oriansj> and I'd be doing it first in C to figure out the logic required before doing the conversion.
04:25:00 <klange> > MenuetOS
04:25:00 <klange> I would say look at Kolibri; Menuet is not viably licensed for such a project.
04:27:00 <klange> But then Kolibri is still only 32-bit (forked from Menuet), the non-FOSS Menuet is 64-bit.
04:29:00 <moon-child> I mean
04:30:00 <moon-child> if it's not opensource, there's a limited extent to which you can ... look at it
04:30:00 <moon-child> even if written in assembly
04:30:00 <klange> It's inherently source-available, you're just not allowed to do anything with that source.
04:31:00 <klange> (I don't know off hand if they actually release the original source files, eg. with comments, and don't care to check.)
04:31:00 <moon-child> yeah, if you disassemble you lose comments, formatting, symbol names, macros...
04:40:00 <FatAlbert> fjklaj
04:42:00 <moon-child> agreed
04:43:00 <FatAlbert> i changed battries to the keyboard
04:44:00 <FatAlbert> i was talking to my mom and im not sure that the two are the actually new ( at least one is because the keyboard is working now )
04:48:00 * kingoffrance .oO( whoever posted a link other day for x86 switching to vga mode 0x13/256 colors/320x200...apparently bochs and qemu, when pxe booting, switching to that mode, then outputting text, they seem to reroute/draw the text to the graphics lol )
05:01:00 * kingoffrance .oO( looking at bdf fonts, i found this gem: https://www.tomsarazac.com/tom/Fun/nethack.html )
05:01:00 <bslsk05> www.tomsarazac.com: Big X11 Nethack Font
05:07:00 <FatAlbert> lol what is that site
05:25:00 <kazinsal> ah, the good ol' days of the internet. where you usually had to know someone at a friendly dial-up provider or be in academia to host a web page, usenet reigned supreme for discussion, and 320x200 porn loaded line by painstaking line
05:28:00 <geist> yah i love how its like bam page loaded
05:29:00 <geist> also wow MenuetOS. back in 2001 when i wrote an article for Dr Dobbs on Newos, menuetos was the other article in the magazine
05:30:00 <Mutabah> It popped up on HN recently I think (or might have been /r/programming)
05:30:00 <Mutabah> quite the blast from the past
05:32:00 <kazinsal> if it popped up on HN I guarantee half the comments are going to be people debating whether or not it should be rewritten in rust
05:32:00 <geist> heh
05:36:00 <bradd> narrowed it down to a rpi 3 a+ or a rpi 4 b. I will be using this just to test my arm code. would the 3a+ be enough to do this? (and will code on the 3a+ be compatible with the 4b?). (the 3a+ is much cheaper so i'd like to go that route if compatibility wont be an issue)
05:36:00 <kazinsal> just get a 4.
05:38:00 <bradd> ok. I've found 2 sellers on ebay for used p4's at around $100 cad. guess I'll grab one of those
05:38:00 <kazinsal> unless you're extremely terribly strapped for cash, the 4 is going to give you better instruction throughput, much more memory, full gigabit ethernet, etc
05:38:00 <kazinsal> also it's a cortex-a72 versus an a53 (iirc)
05:39:00 <bradd> alright, I'll put the order in then. thanks kazinsal
05:39:00 <kazinsal> I'm not the local arm wizard but I am canadian so that counts for something when it comes to sourcing parts
05:40:00 <kazinsal> notably I think canakit is *still* out of stock and will be until at least late summer
05:40:00 <bradd> yeah. all i found was 2 used ones on ebay.ca
05:40:00 <kazinsal> you might be able to get a Pi 400 new
05:41:00 <geist> kazinsal: you did good
05:41:00 <kazinsal> iirc it's basically a pi 4B with a higher clock rate inside a keyboard
05:41:00 <geist> right
05:41:00 <geist> if you can happen to find one cheaper, go for it
05:41:00 <kazinsal> bradd: I managed to add one of these to my cart and it didn't tell me it was a preorder: https://www.canakit.com/raspberry-pi-400.html
05:41:00 <bslsk05> www.canakit.com: Raspberry Pi 400 and Accessories
05:42:00 <kazinsal> $70 CAD without accessories
05:42:00 <kazinsal> $94.90 CAD with a 32 GB microSD and a 3.5A power supply with on/off switch
05:43:00 <bradd> oh nice. thanks. looking at it now
05:43:00 <kazinsal> iirc the keyboard on them isn't bad either. nothing fancy but not totally cheap crap
05:43:00 <bradd> that would still be good for arm osdev testing right?
05:43:00 <kazinsal> yep. grab one of the micro HDMI cables that they sell and you can hook it up to any HDMI display
05:44:00 <bradd> sounds good. ty again
05:44:00 <kazinsal> it's architecturally the same as a Pi 4 B as far as I know
05:44:00 <kazinsal> just a bit faster because it can clock higher with the larger surface area for thermal dissipation
05:44:00 <Mutabah> and a bunch of fancy accessories
05:44:00 <bradd> excellent
05:45:00 <kazinsal> honestly having a hard time not just clicking "checkout" myself
05:45:00 <kazinsal> but I just bought a new leather jacket so I should probably cool it with the frivolous spending for a bit :)
05:47:00 <Mutabah> I got very tempted by one last time I was doing parts shopping... tempted again
05:47:00 <Mutabah> But I'm not sure I'd actually use it... not for long enough to really justify it...
05:47:00 <kazinsal> yeah, today's been a day of "ooh, <thing> is in stock... no, wait, I shouldn't" for me
05:47:00 <Mutabah> then again... if it's beefy enough to youtube...
05:47:00 <vdamewood> I'm half tempted to try using CMake to generate the build system for my OS.
05:48:00 <Mutabah> (My laptop has a thermal management bug, known to hardlock under stress)
05:48:00 <vdamewood> Well, at this point, s/OS/boot code/
05:48:00 <kazinsal> I very nearly bought a 5900X and then remembered that the 7000 series is likely to be out in the late summer
05:49:00 <kazinsal> and then very nearly bought a Line 6 Helix HX effects processor...
05:50:00 <kazinsal> I think when Ryzen 7xxx is out I'll probably buy two -- one to replace my 8700K, one to replace my 2x E5-2620 server
05:50:00 <kazinsal> or maybe a used 5900X for the server
05:51:00 <kazinsal> then the 2620s will go to the great e-recycler in the sky and the 8700K will turn into an osdev test box
06:01:00 <vdamewood> Is it any easier/harder to develop a GUI on AMD vs nVidia GPUs?
06:12:00 <geist> huh! you know, i never thought to try this but if i simply pll out the video card on this ryzen machein i'm using as my server
06:12:00 <geist> it just boots and runs fine
06:12:00 <geist> soooo i dont really need a vid card in it anyway
06:12:00 <geist> i hadn't even thought to try, i assumed it'd just beep at me and not post
06:13:00 <Mutabah> vdamewood: Well, GUI tends to be separate to the video driver...
06:13:00 <Mutabah> but I'd guess that AMD would be slight easier to write a naive driver for, since they provide some level of docs last I checked
06:14:00 <Mutabah> (although, the noveau driver is aparently pretty good on the docs department)
06:14:00 <Mutabah> You can get pretty far along just blitting to a bootloader-provided framebuffer
06:14:00 <vdamewood> Mutabah: I probably should have specified graphics driver.
07:06:00 <kazinsal> geist: oh neat, what ryzen model?
07:27:00 <kingoffrance> https://defuse.ca/b/Nhfe8U5P8Wk9N6DTDE2StZ pw: x silly bochs patch to make "in" from port 0xE9 read from a fifo if an env var is set. now to try qemu :) i actually have serial port code, but haven't tested yet lol
07:27:00 <bslsk05> defuse.ca: Defuse Security's Encrypted Pastebin
07:27:00 * kingoffrance runs away
07:40:00 <kingoffrance> hmm, actually i should close that fd or make it static :/
07:41:00 <FatAlbert> you guys still didn't explained to me what is serial port and what is used for and i hang out with you for queit a bit of time
07:42:00 <FatAlbert> i know what it is only in the context of hardware
07:42:00 <FatAlbert> not in the context of software
07:42:00 <FatAlbert> kingoffrance: let's start with you .. what is `serial port code` ?
07:44:00 <Mutabah> ... Directly calling someone out is kinda rude
07:44:00 <Mutabah> And your initial statement can also be read as rude, as if we should have explained what a serial port is.
07:45:00 <Mutabah> Have you tried searching the internet yourself?
07:47:00 <kingoffrance> when i mentioned above idea few days ago, it was pointed out serial port is easy enough. i dont know albert, only seen them recently.
07:48:00 <kingoffrance> thats too old of a nick not to know what a serial port is :)
08:05:00 <klange> In the general context of computing, I can understand being unaware of serial ports in 2022 since they haven't been included on motherboards in well over a decade, much less actually used by anything, but being even remotely close to OSdev and not knowing what a serial port is... is shocking to me.
08:05:00 <kazinsal> on top of that, if it's been days and you haven't been able to google what something is this is the wrong field for you
08:11:00 <klange> kingoffrance: for qemu, the E9 device will return a readback value (which is 0xe9 by default), but I think it could be patched to use `qemu_chr_fe_read_all` on the same thing it writes to instead... https://gitlab.com/qemu-project/qemu/-/blob/master/hw/char/debugcon.c#L78
08:11:00 <bslsk05> gitlab.com: hw/char/debugcon.c · master · QEMU / QEMU · GitLab
10:56:00 <gog> µ
10:58:00 <zid> pls don't call me out like that in public
10:59:00 <gog> sorry
11:21:00 <kingoffrance> i found an ancient 1994 nawk script to convert a bdf font to a bunch of xbms http://www.ittc.ku.edu/images/AIcons/support/scripts/ unfortunately, it screws up terminus at least :/ luckily, fontforge has scripting https://defuse.ca/b/H8mKjMMDUyT34XAu6wksA4 pw: x i think i have a million things to do before "graphics" but xbm is literally just C code: #define width #define height <array of bytes> lol
11:21:00 <bslsk05> www.ittc.ku.edu: Index of /images/AIcons/support/scripts
11:21:00 <bslsk05> defuse.ca: Defuse Security's Encrypted Pastebin
11:29:00 <kingoffrance> i wonder if you could pre-render ttf or something that way lol
11:29:00 <FatAlbert> gog i can't here ya
11:29:00 <gog> i said 'µ'
11:31:00 <klange> kingoffrance: I have a thing to bake TTF fonts into a C-friendly bitmap format. I used it to produce a version of Deja Vu Sans Mono for kernel debug output.
11:33:00 <klange> It's also a fallback option for my GUI terminal; it's notably faster than my truetype implementation, so it's good for getting better terminal performance especially in software emulation
11:34:00 <klange> Tool: https://gist.github.com/klange/dbcbcb78eb3300be5b3b590f07ea8a87
11:34:00 <bslsk05> gist.github.com: bake.c · GitHub
11:34:00 <klange> Output (with added DejaVu/Bitstream license text): https://github.com/klange/toaruos/blob/master/apps/terminal-font.h
11:34:00 <bslsk05> github.com: toaruos/terminal-font.h at master · klange/toaruos · GitHub
11:38:00 <klange> I would port it to use my own truetype rasterizer, but I don't currently have a monochrome output mode, and I don't have hinting support, so it would look bad, so it uses freetype ;)
11:42:00 <kingoffrance> BDF actually looks plaintext-ish too...
11:45:00 <klange> For real fun, I used to use binary literals for this stuff, and with a bit of syntax highlighting tweaking... http://dakko.us/~k/vga_font.c.html
11:45:00 <bslsk05> dakko.us: ~/osdev/kernel/core/vga_font.c.html
11:46:00 <zid> yea that's cute
11:46:00 <zid> unifont uses a macro instead
11:47:00 <zid> 256 macros, infact
11:48:00 <zid> https://github.com/zid/boros/blob/master/unifont.c#L295
17:15:00 <CompanionCube> https://www.theregister.com/2022/05/10/openvms_92/
17:15:00 <bslsk05> www.theregister.com: OpenVMS 9.2 hits production status for x86-64 • The Register
17:15:00 <gog> o:
17:53:00 <dminuoso> geist: Speaking of "pulling out and running as server", the framework laptop mainboard is a prime candidate for that!
17:53:00 <dminuoso> That thing is a marvellous piece of engineering.
20:07:00 <geist> yah never actually looked at one of those
20:07:00 <geist> CompanionCube: oh neat
20:07:00 <geist> i wonder if can get a hobbyist/etc license for that
20:09:00 <geist> looks like at least for that release it's company only, need to have an existing relationship, etc
20:52:00 <heat> openvms doesn't sound too open does it
21:28:00 <geist> it was named open back in an earlier era of what open means
21:28:00 <geist> i think in the 80s that meant 'can interoperate with other things'
21:28:00 <geist> or something like that
22:02:00 <jimbzy> Yay. I was finally assigned a call sign.
22:03:00 <zid> "GenericCallsign7"
22:04:00 <jimbzy> Just "1"
22:07:00 <geist> you are number 1 to us
22:07:00 <mrvn> mrvn to 1, mrvn to 1, comcheck, over
22:10:00 <heat> that does not sound cool
22:10:00 <heat> you should've asked for something like alpha bravo delta
22:10:00 <heat> way cooler
22:11:00 <jimbzy> Whiskey Tango Foxtrot
22:11:00 <mrvn> are there even still 3 letter callsigns left?
22:11:00 <jimbzy> I've seen 4 char, but never any 3 char ones.
22:14:00 <heat> find the 3 letter callsign you want, find out who has it, murder them, profit
22:19:00 <jimbzy> I'm too lazy to murder anyone...
22:27:00 <mjg> Charlie Romeo Alfa Papa
22:41:00 <jimbzy> I also received my EEPROM reader and logic analyzer. Unfortunately, I don't have time to mess with any of that stuff at the moment.
22:41:00 <jimbzy> Soon...
22:42:00 <mjg> (tm)
23:40:00 <geist> oh one of the little white uh T668 or whatnot?
23:40:00 <geist> i should find mine, have it somewhere
23:40:00 <geist> haven't tried recent software with it
23:52:00 <jimbzy> Yeah, TL866 Plus