<heat>
good thing the manual has 6666 for great devilish vibes
<heat>
6666 pages, that is
<heat>
waiiiiiiiiit this architecture is in reverse, el0 is user
<heat>
i feel stupid
<Mutabah>
It's sensible :) Can't go lower than user, but you can definitely go above kernel
<Mutabah>
(e.g. hypervisor)
lg has quit [Remote host closed the connection]
<heat>
yes, I, erm, forgot
goliath has quit [Quit: SIGSEGV]
<epony>
arm is not confusing, it's simply unoriginal
terminalpusher has quit [Remote host closed the connection]
dutch has quit [Quit: WeeChat 3.8]
<heat>
what does "Current Exception level with SP_ELx, x>0." mean?
dutch has joined #osdev
joe9 has quit [Quit: leaving]
gog has quit [Ping timeout: 265 seconds]
sleider has quit [Read error: Connection reset by peer]
<heat>
actually seems like I could fit all the register saving
<heat>
noice
<geist>
ah sorry. yeah, personally i find EL0 being user and counting up makes total sense
<geist>
the whole inverted thing that x86 did is really strange
<geist>
i think intel personally numbered them backwards from VAX (where they obvoiusly copied the 4 rings from) to be different
<geist>
VAX numbered them 0 as user, 3 as kernel, etc
<geist>
oh wait, no. backwardss. okay same reason then: x86 copied vax :)
<geist>
heat: the SP_ELx is a feature you can set in the PSTATE that sets what the SP register aliases to
<geist>
ie, is SP the current SP_ELn thatyou're currently in, or is it hard coded to SP_EL0
<geist>
unless you need it, you'll be always running in SP_ELn mode
<geist>
the trick with the arm64 16 exceptions is think of it as 4 exceptions { irq, fiq, sync exceptions, serror } and then 4 separate entry points for each one
<geist>
based on where you *came from*
<geist>
oh i wish i had exactly this feature on riscv
<geist>
the idea is the separate entry points are so you can tailor precisely how you save/restore the registers
<heat>
right now I have two variants for the save code (el0 or not), then I branch into arm64_exception_<stuff> (stuff = irq, fiq, sync, serror)
<geist>
yep.
<heat>
where I haven't written that bit yet, but it should call into C code and then restore and get out
<geist>
yoi'd need 3 if you let EL0 run in arm32, for example
<geist>
you could totally tailor your save/restore for only needing to save half the registers, etc
<heat>
i haven't measured yet but actually my entry points could look like "entry: save_regs <el>; bl arm64_exception_sync (straight into C); b exception_out" or something
<heat>
i have plenty of space but not enough for doing inline reg restore
<heat>
do I need multiple exit variants too? or will things mostly fall into "ldp everything, restore sp, restore psr, restore elr, eret"
<heat>
i guess I do need to ".if \el == 0" on sp restore?
<geist>
yeah or i guess you can also save SP_EL0 even when coming from EL1, but that's generally not useful work
<geist>
it's still a banked register that's there, even if you're in EL1
<heat>
when am I expected to get sp0 exceptions vs SPn?
<heat>
I expect the answer to be "when i'm running in SP_EL0 mode", which is when?
xenos1984 has quit [Read error: Connection reset by peer]
<bslsk05>
developer.arm.com: Documentation – Arm Developer
<heat>
thanks. gosh the asm syntax is so weird
<geist>
there's some tricky value to it, but for te most part unless you need it, just use SP_ELx which is basically the default
<geist>
how so?
<heat>
stp x28, x29, [sp, #-16]! works like a push ([sp, offset] exclamation point?)
<geist>
ah yeah. ! is writeback. that is kinda weird
<geist>
but at least consistent with arm32
<heat>
but load seems to use something like "ldp x0, x1, [sp], #16"
<heat>
for pop
<geist>
yah there's a logic to it. what is inside the [] is the address it resolved
<geist>
so oh push you want [sp - 16] basically, and then ! means write back (optional in that case)
<geist>
but for pop you want to use sp as is [sp], and then the #16 is applied after the deref
<geist>
writeback is not optional there, so you leave off the !
<heat>
ah, thank you
<heat>
that makes more sense
<heat>
still... kind of bizarre
<geist>
never tried, you might be able to put a ! in on the pop case, and it's just implied
<geist>
i thought you were going to talk about the mrs vs msr and whatnot
<geist>
that's also consistent, easy to remember which one to use (mrs vs msr) if you think of it as a lkittle mini versio of right to left
<geist>
ie, reading from system register: mrs (move to register from system)
<geist>
and msr (move to system from register)
<geist>
and the operand order has to match up as well
<heat>
yes, that's also weird but somehow kind of made sense to me
<heat>
is sp_el0 just a banked sp register I can use?
<heat>
hm, maybe not
<geist>
sort of. here's the logic: each EL has it's own SP that's banked
<geist>
the SP register is always an alias to either SP_EL0 or (commonly) the current SP_ELn
<geist>
where N is the current EL
<geist>
the SPsel register lets you select that, but the default is SP_ELn
<geist>
it solves the whole TSS problem elegantly: when you switch from user to supervisor mode (EL0 to EL1) the kernel's stack is a banked copy that becomes active
<geist>
probably already know this but just making sure
<geist>
but, if you're in a higher EL you can access the lower SP_ELn via a msr/mrs instruction
<geist>
so it becomes just like any other control register
xenos1984 has joined #osdev
<heat>
yes
<geist>
but that also means if you're in EL1 and you're ready to switch to EL0 you can set the SP_EL0 with just a MSR instruction prior to eretting to it
<geist>
at EL0 of course it's only possible that SP is SP_EL0, there's no other way it could be anything else
<geist>
omg righto.com got ahold of an iAPX 432
<geist>
he’ll probably de-lid it and reverse engineer the whole thing
tiggster has joined #osdev
archpc has quit [Quit: rm -rf /home/archpc]
archpc has joined #osdev
sinvet has quit [Ping timeout: 264 seconds]
heat has quit [Ping timeout: 248 seconds]
<epony>
ain't that a bit too late ;-)
<epony>
just cheat and get the spec
rnicholl1 has joined #osdev
elastic_dog is now known as Guest1481
Guest1481 has quit [Killed (copper.libera.chat (Nickname regained by services))]
elastic_dog has joined #osdev
pharonix71 has quit [Remote host closed the connection]
pharonix71 has joined #osdev
asarandi2 has joined #osdev
asarandi has quit [Ping timeout: 250 seconds]
rnicholl1 has quit [Quit: My laptop has gone to sleep.]
bradd has quit [Ping timeout: 252 seconds]
bgs has joined #osdev
slidercrank has joined #osdev
Ali_A has joined #osdev
Halofreak1990 has quit [Ping timeout: 246 seconds]
slidercrank has quit [Read error: Connection reset by peer]
slidercrank has joined #osdev
danilogondolfo has joined #osdev
TkTech has joined #osdev
Ali_A has quit [Quit: Client closed]
asarandi2 is now known as asarandi
xvmt has quit [Remote host closed the connection]
xvmt has joined #osdev
<immibis>
Mutabah: you can definitely go below user; that's what a VM is. Imagine if you could just make a VM *without* having to cooperate with the kernel
* Mutabah
is away (not here ...)
<immibis>
(well, making a VM is not "just")
<immibis>
certainly without cooperating with a hypervisor
GeDaMo has joined #osdev
gog has joined #osdev
eroux has quit [Read error: Connection reset by peer]
eroux has joined #osdev
Ali_A has joined #osdev
Left_Turn has joined #osdev
Ali_A has quit [Quit: Client closed]
JTL has quit [Quit: WeeChat 2.9]
Celelibi has quit [Ping timeout: 252 seconds]
goliath has joined #osdev
awita has joined #osdev
bas1l has joined #osdev
basil has quit [Remote host closed the connection]
corecode has quit [Ping timeout: 252 seconds]
corecode has joined #osdev
geros has quit [Ping timeout: 252 seconds]
geros has joined #osdev
kristinam has quit [Ping timeout: 252 seconds]
kristinam has joined #osdev
Celelibi has joined #osdev
bas1l is now known as basil
Left_Turn has quit [Remote host closed the connection]
<zid`>
The thing I am watching has some cute dainty shoulders if that helps
<zid`>
we've not seen the legs yet
bnchs has joined #osdev
elastic_dog has quit [Read error: Connection reset by peer]
elastic_dog has joined #osdev
<awita>
Hello guys. I want to implement multitasking with segmentation (no paging). Is it enough with 4 GDT descriptors (code and data for kernel and user) plus the TSS?
<zid`>
4 is slightly too few
<zid`>
null, kernel cs, kernel ds, user cs, user ds, tss
<zid`>
*fingers*
<zid`>
6
<Mutabah>
and that's the minimum assuming you _are_ using paging
<zid`>
can't you just hotswap the user ones?
<Mutabah>
without paging, you'll want the LDT and enough entries there for whatever protection you want to do
<zid`>
rather than reusing them
<zid`>
or use the ldt, yea
<Mutabah>
guess you can...
<zid`>
and tss is single slot on pmode right? it's double in long
<Mutabah>
yeah, single in pmode
<awita>
I am not using paging and I don't want to do it just yet, I wanna know how to do it using only segmentation
<zid`>
It's funny how you need two for tss in long, despite the tss being near useless and just holding a single field in practice
<Mutabah>
Tip: use paging, and ignore segmentation wherever possible
<zid`>
double tip: use paging, and long mode
<Mutabah>
Well, ISTs are useful
<awita>
I know I should ignore segmentation but I want to do it as an exercise to understand the differences and such
<Mutabah>
and it needs two entries to fit the full 64-bit address
<awita>
What should I use the LDT for? Two entries (code and data) per process?
<Mutabah>
No idea, as implied - I don't use it
<Mutabah>
segmentation (especially x86 segmentaton) is just a relic of the past.
<zid`>
info on how to do this "properly" will likely be thin on the ground
<zid`>
as nobody does it this awy
<Mutabah>
maybe look into how DOS was structured if you want to..
<awita>
hmm that makes sense, I'm not finding much info about it
<zid`>
You can set it up, but I have no idea how fast/slow it will be via various methods
<zid`>
ldt or gdt based
<awita>
Is paging used everywhere? I thought small embedded devices didn't have a MMU
<zid`>
small emedded devices without an mmu just don't use memory protection
<zid`>
they basically use soft-threads
<awita>
I want to do that maybe
<Mutabah>
and cooperative memory management (i.e. don't step on each others toes)
<awita>
Maybe it's easier to just use paging but I don't fully understand yet the whole relationship between paging, physical memory allocator, the heap, etc.
<zid`>
watching the new slime datta ken movie, I have known her for 30 seconds but I would die for raja
<zid`>
paging is just a lookup table
<zid`>
from fake addresses to real addresses
<zid`>
each process gets its own lookup table
<zid`>
so that you can re-use addresses without having to re-use physical addresses
<Mutabah>
awita: You can skip paging for now if you want... but it does make implementing some things a lot easier (as you can just pick where memory goes)
<zid`>
i.e every process loads to 1MB, but is actually at 1MB, 2MB, 3MB, etc in physical memory
<awita>
I see
<awita>
I have done a pmm for now (a bitmap-like structure where i can allocate and free frames). What I want to do now is some sort of heap for the kernel. But I don't fully understand because most resources I find online do the heap and paging almost simultaneously
<zid`>
well you're done if you're not doing virtual memory
<zid`>
that's the point
<zid`>
your physical memory is your heap, go nuts
<awita>
just like that?
<zid`>
what else is there?
<awita>
i dont know :(
<zid`>
Well think about what you want to *achieve*
slidercrank has quit [Quit: Why not ask me about Sevastopol's safety protocols?]
<zid`>
You want to be be able to implement 'give me memory' and 'have this memory back' functions, the former won't give you the same address twice until the latter is called on it
<awita>
i don't need memory protection for now. I can allocate contiguous frames with my pmm, and I would like some sort of kernel malloc to do linked lists and stuff
<Mutabah>
they're very different ... but you need the PMM to be able to implement the heap, and the heap is very useful - so it often the reason for the PMM
<zid`>
if you want byte-granularity allocations then you just need to write that code
<zid`>
maybe with a cool tree, or some lists, or whatever
<zid`>
or a list of trees!
<awita>
Yeah, I would like byte-granularity allocations and I think I need linked lists or some other data structure for that
<awita>
But I need some sort of dynamic allocator to do that, right? Or I don't because I'm in kernel mode?
<zid`>
depends what you mean by dynamic allocator?
<awita>
kernel malloc
<zid`>
That you don't have virtual memory changes nothing, you just replace the mmap part or whatever the example you found that uses virtual memory, with something that finds arun of free physical pages in your bitmap
<awita>
right now my pmm returns me a pointer to a 4k frame because the bitmap keeps track of 4k chunks
<zid`>
(virtual memory can turn any set of physical pages into a run of linear virtual pages, which is a good cheat)
<awita>
I see
<zid`>
like I said, it's just a lookup table that turns one into the other
<zid`>
so you can do things like [1,2,3,4,5] -> [3,2,5,4,1]
<awita>
Thank you. I'm also gonna go back to my notes, I think I need to reread some things about this haha thank you guys!
<Mutabah>
A useful note with combining paging and a heap: You just designate "this region of memory (e.g. 0xC080_0000 to 0xE000_0000) will be my heap", and then get the VMM/PMM code to make pages within that region valid (i.e. allocate and map frames there) as you need more valid memory
<zid`>
'give me a range of 20 pages' so you can back a malloc(20*4096) turns into the very easy task of 'pop 20 random addresses off my free page list' with paging
<zid`>
and malloc turns into "find a free range of addresses to return"
<zid`>
which is basically the same problem you started with
<zid`>
finding a run of 20 contiguous pages
<Mutabah>
except that now the run is in a better-defined (and possibly) region of address space
dude12312414 has joined #osdev
<gog>
depending on your kmalloc() implementation and alignment requirements, byte-granularity isn't possible. the smallest alignment is going to be 4 bytes
<gog>
for me kmalloc() has two paths, < 4KiB and > 4KiB
<gog>
less allocates from the heap with an overhead of 4 bytes
<zid`>
meanwhile I am lazy, and just round everything up to a page and don't support >4k, muhahaha
<gog>
more allocates from vm_alloc with no direct overhead
<zid`>
glorious solution
<gog>
but then there's overhead because it creats a new vmt_node in the tree
<Ermine>
gog: may I pet you
[itchyjunk] has joined #osdev
<Ermine>
hi btw
<lav>
i hate mondays
<zid`>
Have you considered how that makes monday feel
<Mutabah>
Good thing it's Friday
<lav>
no
<lav>
/msg monday omg i'm so sorry i didn't mean to hurt you
<mrvn>
Does zfs has a "mdadn --write-mostly" equivalent now?
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
bauen1 has quit [Ping timeout: 246 seconds]
bauen1 has joined #osdev
<kof123>
i think cartoon garfield was bill murray, so garfield is a ghostbuster that has a reoccuring groundhog day.
<kof123>
if i can do a "kmalloc" its not hard, im sure i will run into a wall at some point but...
<kof123>
You want to be be able to implement 'give me memory' and 'have this memory back' functions, the former won't give you the same address twice until the latter is called on it <-- what zid said. however that is accomplished, that's a interface
<kof123>
i did see somewhere like v6 unix ...you could free() then realloc() the same pointer and this was supposed to work (maybe only if no free or malloc or realloc in between?)
<kof123>
but that was obsoleted long ago surely
<kof123>
braindead malloc: void * start = 0x0 void * end = 0xFFFFFFFFFFFFFFFF void * first = NULL (pointer to first allocation) allocation header = sizeof(void *) first allocation gets a header at 0x0, pointing to NULL (no other allocations yet) then the allocated data follows, however many bytes caller requested. update "first" to point to the first allocation. then a 2nd allocation comes? follows the first, same format: he
<kof123>
r (pointer to next node in linked list), followed by the caller/user-visible allocated region for the 2nd allocation. as "bookkeeping" for the 2nd allocation, make the first allocation's header point to the second. header of the 2nd allocation points to NULL. |||| an "inlined" linked list (pointers to nodes stored next to the user-visible addresses) is easy.
eroux_ has quit [Read error: Connection reset by peer]
* kof123
coughs up hairball. dead simple, and you can spot the problems...what about threads? how slow does this get? what happens when i hit the end? what about alignment?
<kof123>
*what about alignment of "headers" too... is my target strict about that?
<kof123>
easy addition: add a "last" pointer to the last allocation, so you dont have to crawl it from start to end to find free space
eroux has joined #osdev
Halofreak1990 has joined #osdev
* ghostbuster
crosses streams with kof123
awita has joined #osdev
<kof123>
maybe it was dave coulier. i dont know these things
<bslsk05>
'McLaren car spotted' by Mister_Jacobz (00:00:06)
<kof123>
all you are really doing with braindead malloc is hiding a header. the art of lying to the user must be carefully cultivated
<heat>
zid`, lol
heat_ has joined #osdev
heat has quit [Ping timeout: 246 seconds]
zid` has quit [Read error: Connection reset by peer]
zid has joined #osdev
xenos1984 has quit [Ping timeout: 248 seconds]
xenos1984 has joined #osdev
kompowiec has joined #osdev
kompowiec has left #osdev [Leaving]
<gog>
meow
<gog>
i'm a good developer but i'm also too eager to help and cause problems for myself in the process
<zid>
nice
awita has quit [Ping timeout: 276 seconds]
<sakasama>
Don't worry gog. I've collected all of your problems and added some of my own.
<gog>
ok i'll fix them
<gog>
i will fix everything
<gog>
i think my boss was a little upset at me
<gog>
but also the thing i did wasn't really that big of a deal, it just is contrary to our operating procedure
<gog>
idk i'm gonna try not to worry too much
<gog>
i keep thinking i'm about to get fired because i'm not doing enough or doing things well enough
<gog>
but there's not even been so much as a big serious meeting about stuff
<gog>
and they'd have to get past my union rep
<gog>
idk i think i'm just too used to american work culture
innegatives has joined #osdev
<innegatives>
What were two types of CPU emulation called? One where you emulate every detail of CPU and in other where you emulate operations with just language intrinsics?
<GeDaMo>
Cycle-accurate?
xenos1984 has quit [Ping timeout: 248 seconds]
<innegatives>
right, but there were simpler terms for them
<gog>
emulator and simulator?
<nortti>
HLE / LLE?
<innegatives>
yeah
<innegatives>
HLE LLE
<innegatives>
QEMU is HLE, right?
<gog>
qemu does multiple things
<gog>
depending on the cpu type it's emulating
<gog>
for x86 it has a few modes
<pitust>
innegatives: i dont think thats what HLE means
<pitust>
well, HLE means you intercept library calls and not simulate hw
<jimbzy>
Mode 13h
<jimbzy>
:D
<pitust>
qemu emulates instructions directly (tcg) or uses special hardware to run them (hvf, kvm, haxm)
<pitust>
and it emulates all the hw attached
<gog>
omg he even told me "good job" just now lmfao
<gog>
because of something i caught ahead of time
gog has quit [Quit: Konversation terminated!]
innegatives has quit [Quit: WeeChat 3.8]
xenos1984 has joined #osdev
<epony>
not enough IRC petting in your employer's life
sinvet has joined #osdev
slidercrank has joined #osdev
JTL has joined #osdev
bauen1 has quit [Ping timeout: 248 seconds]
bauen1 has joined #osdev
<geist>
i think the real problem is theres no one definition of HLE and LLE, it depends on what sort of angle you're approaching it from
<geist>
but they left, so *shrug*
terminalpusher has joined #osdev
danilogondolfo has quit [Remote host closed the connection]
gog has joined #osdev
<lav>
hi gog
<kof123>
you take your circuit, and then it should be flexible, so software. and then the software emulating hardware needs to emulator other hardware. and then its too slow so it needs hardware features, and then...
<kof123>
its a vicious cycle of depravity, never knowing who is simulating who
<geist>
right and then it turns out the universe is a simulation, etc
<kof123>
really? this calls for a simulation to simulate it then, it's the only way
<geist>
or you simulate them, that'll teach em!
<heat_>
geist, is the GIC hard
<geist>
well, which gic specifically? v2 or v3?
<gog>
we call that the speed of light
<geist>
v2 is much simpler than v3
<heat_>
one of the versions, I don't know which I'll need
<heat_>
but qemu-virt
heat_ is now known as heat
<geist>
if you have less than 8 cores, it'll default to v2
<geist>
once you go over 8 cores it'll switch to v3
<geist>
*or* you can override it with ,gic_version=N
<geist>
*or* if you're using KVM it uses whatever gic version KVM emulates
<geist>
not a great answer, but it basically means you can probably start with v2 for now, which is a lot simpler
<heat>
are qemu monitor commands useful here or am i skrewd
<geist>
i dont think there are any monitor commands that have anything to do with gic, no
<geist>
ie, 'into pic' or whatnot does nothing
<geist>
info
<heat>
:)))))))))
<geist>
so gic v2 was designed back in the day when ARM was not trying to build hyper complicated, uber designs. so it's a good starting point
<heat>
shoot me
<geist>
heh, you've had it too easy up till now, staying on well trodden path
<geist>
this is where you get to grow up and be an ADULT
<heat>
why does no one see the need to make qemu commands work
<heat>
even riscv has this
<geist>
because qemu commands are for CHILDREN
<geist>
actually no, riscv doesn't have info plic
<geist>
which i was literally looking for yesterday and sad it didn't exist
<heat>
but riscv has info mem which is great
<heat>
or is it info tlb? one of the two
<geist>
sure, but one info command does not mean all commands are
<geist>
but yes it does have a mem command, that is true, but otherwise most of the other info commands are not there
<geist>
anyway gic v2. focs on that for now. it's fairly straightforward. when you get to group0 and group1, ask me about it
<geist>
it's kinda tricky because ARM doesn't explain it properly
<heat>
what is that?
<geist>
that was the big hurdle i had
<geist>
read the spec first, so you know what i'm talking about
<geist>
then we can discuss it
<heat>
;_;
<geist>
well, you *are* going to read the spec right?
<heat>
of course
<heat>
I do love a good spec
<geist>
yah do that first, if group0/group1 makes sense, perfect, but it probably wont, so dont stress about it
<heat>
not the ARM ones, but tis what it is
<geist>
well GICv2 is simple enough because it was designed back in the late 2000s, before v8 ad virtualization and all this other stuff permeated everything
<geist>
one of the big things that v3 adds is all the virtualization stuff, which as is with all ARM things makes it much more complicated
<geist>
notably because gicv3 is like an uber intel/amd APIC-V or whatnot, with full virtualization support
<geist>
which then permeates the v3 spec in a way that's confusing as shit
<geist>
whereas v2 is like 'here are interrupsts, here are the registers to fuck with them'
<heat>
i think ARM specs are not written for hoomans
<heat>
anyway I still need to write the timer stuff, I found a nice succinct guide on that
<heat>
planning to bring up the timer stuff, then the GIC irq stuff
heat has quit [Remote host closed the connection]
<geist>
also notably v2 has: you can have up to 8 cpus, so here's a bunc of 8 bit fields that represent things that have anything to do with cpus
heat has joined #osdev
<heat>
gosh darnit
<geist>
so clearly that's not scalable past 8, which is why v3 switches to a completely different mechanism for representing multiple cpus
<heat>
yeah
<geist>
x86 apic has the same problem deliverying to > 32cpus, etc
<heat>
no, x86 apic has a problem delivering to >255
<geist>
ah yeah 255
<heat>
they don't use masks, they just use a LAPIC number I'm pretty sure
<geist>
i think there is some sort of mask support, or maybe that was the super old delivery method
<heat>
actually implemented this some days ago, was fun
<geist>
for a summary: gic v2 uses an 8 bit mask for anything to do with cpus, including IPI delivery. so 0-7 cpus
<geist>
v3 switches to using the full MPIDR id (basically same as APIC) as all their cpu targets, and for masking i forget how that works precisely
<geist>
but then v3 can't easily do multiple cpu delivery without O(N) deliver to each cpu or a single broadcast
<geist>
but so it goes.
<geist>
v3 can support something like 16k or 64k cpus, so it works out
<geist>
also FWIW v2 and v3 i think both support up to 8k interrupts, so its at least flexible there
<geist>
at the expense of being more dynamic. more stuff to discover
<geist>
personally i think GICv3 is a fine solution, it's just fairly flexible and thus complicated
<heat>
when do I need to use # in arm64 asm?
<heat>
I can't tell
<geist>
i forget honestly
<geist>
like, i just sort of 'know' at this point because i've written enough of it
<heat>
like mov x0, -14 and and w1, w1, 0xff Just Works
<geist>
but i can't tell yu the rules. also i think i use it more often than i need to. i think it's only really mandatory if it's ambiguous
<geist>
and most of the time it isn't
<heat>
ah
<geist>
one thing arm does *not* do is it doesn't use different opcode mnenomics for say immediate vs not instructions, so there is some parsing ambiguity
<geist>
vs ISAs like mips or POWER or riscv where there's an 'i' variant of instructions that take immediates, etc
<geist>
(though on riscv the assmeber seems to take either)
<heat>
i have to say that the arm64 asm looks weird. just a weird syntax
<geist>
is it the first time you've written a lot of non x86?
<geist>
well i guess you wrote a bunch of riscv
<heat>
no, I wrote riscv before
<geist>
yah ARM64 sits somewhere in the middle. it's risc but it's clearly a lot more complicated, and there are some weird holdovers from arm32 like ! for writeback, etc
<geist>
but then it also has a lot more features than riscv (like writeback) so you have to have a way to signal it, etc
<heat>
riscv made sense to me (very simple, lots of variants, lots of magical voodoo assembler pseudo-insns)
bnchs has quit [Read error: Connection reset by peer]
<geist>
i've been writing arm asm for like 22 years so i can't remember a time where i didn't really grok it
<geist>
yah there is a particular zen to riscv that you kinda get into
<heat>
like mov x0, -14 is something I would never expect to work on a risc
<geist>
feels a bit like working with say a 6502 or something. you can hold the isa in your head so you get pretty good at it
<heat>
i was expecting something really obtuse like a "load immediate"
<heat>
but nope, mov x0, -14 Just Works
<geist>
ah yes, the pseudo instructions are pretty nice in riscv. *at the expense* of leaning on assembler and linker relaxations, which arm does not do
<heat>
this is an arm64 thing
<geist>
in the case of ARM there is never any linker relaxations, so what you write is what you get
<geist>
well, no the arm64 thing just has a larger immediate range
<geist>
if you try to mov a really large immediate it'll gripe at you, and there's no pseudo li equivalent
<heat>
I think i've seen a funny syntax around, something like "ldr x0, =imm"?
<geist>
yeah be very careful about that. that gets tossed around a lot, but that's mostly a legacy arm32 thing
<geist>
i think that works in arm64, but it's highly recommended you not do it
<geist>
OTOH recommended alternative is even harder to write
<heat>
whats the sanctioned way to do it?
<geist>
the sanctioned, modern way to do it is to let the compiler do it because why are you writing assembly
<geist>
it's one of the parts of the ISA i do not like
<heat>
.pushsection .rodata; val: .dword <imm>; .popsection; ldr x0, val
<heat>
:P
<geist>
the underlying mechanism is a series of mov+movk instructions
<geist>
but then it depends a lot on the exact constant
<geist>
we have some sort of macro in zircon to synthesize that, something like MOVIMM(x)
<geist>
but you wish the assembler would just do it
<heat>
oh cool just noticed riscv64 support landed!
<geist>
anyway the modern reason is modern arm64 cores suggest you use a series of mov+movk instructions if you want to get a large constant in it, because the isa has some pretty sophisticated immediate load and shift and or instructions, so you can usually get it into a regitser with 1-3 instructions, and a modern core can chew that shit up
<geist>
vs the whole 'load from a rodata block' which was the arm32 thumb2 way of doing things, but is otherwise slower on real hardware
<geist>
yep. starting working on SMP today, like when i stop talking to you :)
<geist>
hey comment on it in discord so i can say yay!
<geist>
yah thing is even that macro isn't really super sufficient, it can't look at all the permutations of clever ways to get stuff into a register
<geist>
but the cheesy but functional way is mov (16 bit unsigned immediate) + up to 3 movks (unsigned 16 bit immediate, shifted by multiples of 16, orred into the register)
<geist>
note that's distinct from loading a PC relative address, ARM64 has a very similar thing to riscv auipc + 12 bit offset
<geist>
basically identical, which is what the compiler will use most of the time
<geist>
it's uh.... adrp
<heat>
this seems like something that could use some good ol linker relaxations :)
<heat>
on something like mov x0, $addr where addr is something you can only know at link time
<geist>
yah, for literals i think the idea is the compiler can relax that at compile time, but for proper addres stuff yeah
<geist>
agreed.
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<heat>
geist, where are these "ARM programmer's guide" pdfs from?
<heat>
linux kernel mm has changed heaps since 2.4
<heat>
although the principles still apply
<mrvn>
You have to ask yourself: Why are you loading absolute constants?
<innegatives>
heat: is there any newer resource out there?
<heat>
no
<heat>
some people are writing them at the moment
<heat>
but one of the big problems on linux mm is that no one wrote anything down for 20 years
<innegatives>
heat: who are writing what?
<mrvn>
linux mm also started with physical memory and didn't allocate everything virtual.
<heat>
some people are writing books, resources at this precise moment about linux mm
<innegatives>
heat: who? links?
<heat>
i don't have links, sorry
<mrvn>
I have a Linux 2.4 book somewhere
<mrvn>
innegatives: you can be sure that by the time anything comes out on dead trees some things will have changed.
<heat>
but what do you want to know, anyway?
<innegatives>
heat: i want to write some weaksauce security tools for insight into my running Linux to detect possible malicious activity when it happens
<mrvn>
and how would that look like?
<innegatives>
it doesnt have to say "yes you have a virus", if i can peer into MM i can possibly make out the trends
<mrvn>
and how would the trend look like?
<mrvn>
what would you call suspicious?
<innegatives>
basically have some idea of what normal operation looks like and then investigate oddities manually
<heat>
with MM? weird choice
<innegatives>
what would you choose for that?
<mrvn>
I think it would be nice if security fixes for the kernel would include a macro to report "task <X> hit CVE4435" or something.
<heat>
filesystem, etc would be a lot more helpful
<innegatives>
wouldnt fs be easier to not touch for some rootkit
<heat>
versus memory management. viruses allocate memory the same way as normal programs :)
<innegatives>
mrvn: damn thats a good idea
<mrvn>
There is only one virus on my computer: firefox
<mrvn>
If you have a rootkit it will try through a bunch of exploits trying to find one that wasn't fixed. Should be easy to detect that way.
<innegatives>
mrvn: would it be a good project to actually do that? check if processes are hitting fixed cves?
<innegatives>
ok
<mrvn>
innegatives: I would think so.
<innegatives>
any idea why hasnt it been done yet?
<heat>
because it's not very useful
<heat>
process tried to pwn you, it failed
<heat>
what now?
<innegatives>
how do you know it failed
<heat>
because the CVE is fixed
<innegatives>
its as likely to succeed
<innegatives>
if it checks more than one exploit
<heat>
heck you can hit a CVE by accident too
<mrvn>
heat: now the admin can kick the user from the system.
<heat>
what then?
<heat>
there have been plenty of silly CVEs over the years
<innegatives>
well dont include silly ones
<mrvn>
heat: if you get 50 hits for CVEs in a row you know it was hacking.
<heat>
I'd get *really* upset if some process accidentally hit dirty COW when forking and it explicitly crashed
<innegatives>
its good way of finding zero days, isolate process hitting cves and check if it has anything novel
<heat>
no?
<heat>
if you have a zero day, you don't need to check old CVEs
<mrvn>
heat: why would it crash? Nobody said anything about changing the behavior. Just an option to log.
<heat>
therefore, thou hast been fucked
<mrvn>
I think he means when a rootkit tried 50 CVEs and fails and then does a 51st thing.
<heat>
a logging DoS? through all the accidental CVE hitting
<mrvn>
it's not like you can't rate limit logging
<mrvn>
In fact I would give each CVE a score and add that to the processes CVE-counter. Every 100 count or so you log if the rate limit isn't hit.
<mrvn>
Something you hit accidentally could have a score of 1, a brand new root exploit could be 100.
<innegatives>
how do you know brand new root exploit?
<innegatives>
oh you mean brand new
<mrvn>
innegatives: fixed yesterday and has it's own mascot.
<innegatives>
right
<mrvn>
Things you would expect people to try that wouldn't happen accidentally.
slidercrank has quit [Ping timeout: 265 seconds]
<innegatives>
i was more interested in detecting patterns of already established rootkits rather than preventing new processes from stirring shit
<innegatives>
any pointers for that?
<mrvn>
You know what would be really cool? Make it so it works with the kernel hot patching or probeing interface.
<mrvn>
innegatives: I don't think any rootkit has any pattern you can easily detect in the MM.
<mrvn>
But hey, there could be. Go and try out 1000 known rootkits from the past and compare their patterns to other programms.
<mrvn>
.oO(Add a neural net chip to the PC and hack it 100 times to teach it what getting hacked feels like :)
scaleww has joined #osdev
* kof123
lowers hat, squints eyes, spits the only difference between a rogue program and a sysadmin is a badge
<kof123>
or developer, or ...
<kof123>
ceo
<heat>
why is arm64 so complicated and simple at the same time
<zid>
It's there to annoy you, amd64 is up-front about it being complicated
<zid>
arm64 gives you a false sense of security so it can baffle you
<heat>
nothing gives me the same rush as looking at good old x86 descriptor tables
<heat>
like, whats the point of a clock if I don't have to magically figure out its frequency with other, worse clocks
<zid>
it's educating you to not trust clocks
<zid>
And that you should have code to detect bad clocks
<zid>
if anything it's looking out for you like a real bro
<sakasama>
In the past, people called this process "courtship".
<zid>
oh is that what all those privmsgs you send me mean
<zid>
I did wonder
Burgundy has joined #osdev
<mrvn>
try finding out how much physical memory a linux has.
<mrvn>
And no, a 16GB system does not have 15.73G of memory.
<sakasama>
zid: Tell me more about your clock. I'm listening.
<heat>
geist, is the distributor like the IOAPIC and the cpu interfaces the individual LAPICs?
<geist>
yah
<geist>
and gicv3 lets you have multiple distributors, etc, much like having multiple ioapics
<heat>
i swear, half the ARM manuals are not useful
<geist>
yep. the gic manuals are particularly bad, which is why i recommend v2 first
<mrvn>
heat: ignore the 32bit half. :)
<geist>
the overall concepts are not presented well enough and then it drives you directly into the deep end
thatcher has quit [Remote host closed the connection]
<mrvn>
geist: +1 on that
<geist>
the other key thing to really grok is PPI, SPI, and SGI
thatcher has joined #osdev
<geist>
i dont know if it covers that well, but you need to just basically memorize what those mean, write a cheat sheet if youd ont have it
<geist>
because they're used all over the place and the exact difference matters
<geist>
also memorize the range they use: 0-15 is SGI, 16-31 is PPI, 32+ is SPI
<geist>
that also kidna feeds into various design choices that will seem weird if you dont grok that
<heat>
are SGIs just IPIs?
<heat>
"The mechanism for signaling an interrupt to the processor is IMPLEMENTATION DEFINED. " IMPLEMENTATION DEFINED
<mrvn>
Protonenpumpenhemmer (PPI)? really?
<mrvn>
A Private Peripheral Interrupt (PPI) identifies an interrupt source, such as a timer, that is private to the core, and which is independent of the same source ... more like it
<geist>
software generated interrupts, yes
<geist>
heat: yah that's also part of the annoyance. the whole gic thing is written very processor neutral
<geist>
like, 'hey alls we do is signal an interrupt, up to the processor to do it'
<mrvn>
What's spi stand for?
<geist>
but you can generally assume the interrupt is routed to the IRQ and FIQ lines
<geist>
Shared Peripheral Interrupt
<geist>
ie, external hardware
<mrvn>
does that include basically every pheripheral?
<heat>
yes PPI seems like processsor-local irqs (i.e ARM generic timer), SGI seems like IPIs, SPIs seem like normal IRQs (PCI, whatever)
<geist>
but seems like you could, for example, wire up a gic to a riscv core. maybe have one wired to M mode and another wired to S more interrupt
<geist>
mrvn: if it's not local to the cpu yes
<mrvn>
Stupid broadcom chips doing their own interrupts makes this really confusing.
<geist>
yep.
<geist>
since virtually all other arm vendor on the planet uses a gic
<mrvn>
bcm too, now
<mrvn>
You get the worst of both both worlds.
<geist>
and it's a spec, so vendors can implement their own gic (ie qualcomm) but as long as it basically follows the spec yay
<geist>
yep.
<heat>
gicv2 is the *simple* one?
<heat>
fucking hell
<heat>
can't wait for gicv3
<heat>
gicv2 has 200 pages of spec, gicv3 must have 800
<geist>
yeah. it does
<heat>
lmao
<geist>
uh, 930 pages to be precise
<heat>
lol
<heat>
so the APIC is the simple one here, great
<geist>
as is usual things are being presented in great detail, and once you figure out the overall concepts, which it's bad at presenting, you can figure out what to find
<geist>
but it's still hella complicated
<geist>
also there's a lot of mention about arm32 and virtualization that you probably dont need
<geist>
but aren't discussed as separate topics, more inline
bgs has quit [Remote host closed the connection]
<heat>
ok, whats this grouping thing and why should I care?
<heat>
seems like a bunch of secure world garbo to me?
<mrvn>
I really want an intelligent doc format where I can say: I'm not in 32bit, I'm non-secure, im EL2. show me only relevant stuff
<geist>
yes
<geist>
heat: basically for all general use cases, iirc group0 == secure, group1 == non secure
<geist>
so you'll want to set everything to group1
<geist>
i think functionally that equates to group0 wires to the cpu's FIQs and group1 wires to the cpu's IRQ pin
<geist>
and then EL3 will take ownership of FIQs as its own
<geist>
iirc i think that's how it works in practice. i might be slightly wrong on some details there, havent' implemented a secure monitor personally
<heat>
I think group0 is always wired to IRQ and group1 can be wired to either irq or fiq
<heat>
at least I think I read that
<geist>
yeah i forget
<heat>
what does "register is secure" mean?
<heat>
i would assume I wouldn't be able to access it from the non-secure world but they say AIAR, etc are secure. which refer to group1 and supposedly are the ones i should use
<heat>
(I think)
<geist>
i think that's what it means yes
<geist>
hmm, maybe you're supposed to set all yours to group0. but i just seem to remember it was backwards from what i remember
<heat>
i'll be the first ARM soc vendor to integrate an ARM core with the PLIC :P
<heat>
trashy PLIC and CLINT >> GIC confusion
<geist>
FWIW i dont think apple uses gic on their stuff either, but then they also dont implement secure more
<geist>
mode, so they dont have an EL3
<heat>
oh yeah do you have APLIC support already?
<geist>
nope. far as i know it only exists on qemu
<geist>
even linux doesnt have upstream support for it
<geist>
havne't really sat down to grok it yet
<heat>
have you tried zircon on the visionfive?
<geist>
not yet
<geist>
will probably do that in the next few months
Left_Turn has quit [Read error: Connection reset by peer]