<dh`>
and during traps it remember the CPU number in the MMU register that's supposed to be there for pointing at the page table base, since the hardware doesn't actually interpret that
<clever>
software mmu?
<dh`>
because students write the VM system, there can't be magic special mappings
<heat>
that's dope
<dh`>
iirc this scheme was based on what linux mips was doing at the time; I have no idea why they weren't using per-cpu mappings
<dh`>
the provisional riscv port so far uses the tp register as the kernel thread pointer
<clever>
dh`: would that thread exist in both user and kernel? 2 stacks to the thread?
<dh`>
yeah, like most conventional designs each userlevel thread manifests in the kernel as a kernel-level thread with a kernel-level thread stack
<dh`>
and there are some other kernel-only threads that do things like sync the disks
frkzoid has joined #osdev
<clever>
i was thinking earlier about how to do a EL3 or EL2 in LK, where you have a function call that drops to a lower level and resumes a guest
<clever>
and when the guest traps or syscall's, you return from that function
<heat>
that seems possible with setjmp longjmp magic
<clever>
but ive also heard of other kernels, where a syscall/irq starts fresh at the top of a new stack
<clever>
and you may then have to kinda context-switch into the right kernel thread?
MiningMarsh has quit [Read error: Connection reset by peer]
MiningMarsh has joined #osdev
<clever>
heat: the EL2->EL1 change seems easy enough, just set the saved pc/status, and eret, the tricky part is getting it to return from that upon any exception...
<clever>
each EL has its own stack pointer right?, so the stack will be at that function call upon the exception?, but the exception prologue would want to return from the exception
<clever>
so you kinda have to skip a stack frame?
<dh`>
all that kind of stuff seems to me like borrowing trouble
<clever>
dh`: why?
<clever>
its the most logical solution i can see, having read the low-level /dev/kvm api
<dh`>
because the code to do stuff like that at trap time is extremely delicate and really easy to get wrong, and then undebuggable
<clever>
yeah, thats the tricky part
<dh`>
also in general if you leave anything pending in the kernel when you go back to userland (or anything less trusted) you're begging for it to never return or crash and then you have to do some kind of recovery on that context somehow
<clever>
dh`: but you could also do what heat said, setjump before you eret, and then longjmp from the exception handler, does that sound safe?
<dh`>
and that's another pile of delicate and difficult to debug code that also rarely gets exercised
<dh`>
in general my recommendation is to always unwind your kernel state and do any wild gyrations at the trap handler level
<dh`>
like traditional signal delivery works
<dh`>
because while it's not free, it's relatively straightforward to get right
<dh`>
but there's a lot of stuff related to supporting kvm-style guests that I've never really thought much about
<clever>
that reminds me, the general design i was thinking of, was to run LK in EL2, and the guests in EL1
<clever>
but normal linux kvm, runs linux in EL1, and hypercalls into an EL2 stub, to do any hypervisor actions
<clever>
which then returns into a guest EL1
<clever>
but geist also mentioned a new armv8 extension, where you can technically be in EL2, but all of the EL1 registers alias into their EL2 counterparts
<clever>
so linux can run fully in real EL2, but still be coded as-if it was in EL1
gog has quit [Read error: Connection reset by peer]
<clever>
and then it doesnt have to EL1->EL2->EL1
<dh`>
I also have 0 knowledge of this arm stuff :-|
<clever>
arm and x86 name the permission levels in the oposite direction
<clever>
EL3 == secure monitor, the most powerful, EL2=hypervisor, EL1=kernel, EL0=userland
<clever>
when you transition to a lower level, you choose what pc/status reg pair the cpu atomicly swaps into
<clever>
and the current EL is in the status reg
<dh`>
and I've also disliked the idea of having fixed levels, it seems like there should be machine-monitor level and everything else should be recursive instances of the same stuff
<moon-child>
capability hardware!
* moon-child
hides
<dh`>
but everybody has instead rushed to add special hypervisor-level crap to the machine architectures, with the result that either you can't have guests of guests or it takes a lot more work
<clever>
dh`: arm also lets levels be optional, if your kernel started in EL1, and there is no EL3/EL2 firmware, it is impossible to tell if EL2/EL3 even exist
<clever>
its functionally identical to if EL2/EL3 dont even exist
<clever>
dh`: yeah, nested virtualization isnt really supported at the hw level on arm, EL2 can setup a second level of paging tables, so EL1 tables automatically get translated
<heat>
oh yeah something I forgot to complain about but I really want to: a good portion of facebook recruiting emails get tagged to Social by gmail
<clever>
but if your doing nested virt, i would think you would have to shadow the inner hypervisor guest->guest tables
<clever>
you would also need to track if its a guest of a guest currently running, and forward traps to the right guest level
<dh`>
you also need to virtualize everything that makes it look like you know which level you're on
<dh`>
iow, a lot more work
<clever>
yeah
<clever>
and EL3 cant do nested paging tables
<clever>
so you cant use that to run multiple EL2's
<clever>
EL3 is generally reserved for TPM type tasks
<clever>
when a system is setup for security, then EL3 controls what code can access key storage, and can either block booting non-signed kernels, or disable key-storage access when booting unsigned kernels
<clever>
or destroy all key material before you boot an unsigned kernel
MiningMarsh has quit [Read error: Connection reset by peer]
MiningMarsh has joined #osdev
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
MA-SA-YU-KI has quit [Quit: Connection closed for inactivity]
MiningMarsh has quit [Ping timeout: 245 seconds]
MiningMarsh has joined #osdev
mykernel has quit [Ping timeout: 240 seconds]
[itchyjunk] has quit [Ping timeout: 240 seconds]
mykernel has joined #osdev
[itchyjunk] has joined #osdev
mykernel has quit [Client Quit]
air has quit [Ping timeout: 245 seconds]
gildasio has quit [Remote host closed the connection]
air has joined #osdev
gildasio has joined #osdev
zaquest has quit [Remote host closed the connection]
andydude has quit [Quit: CoreIRC for Android - www.coreirc.com]
the_lanetly_052 has joined #osdev
vdamewood has joined #osdev
vinleod has joined #osdev
vdamewood has quit [Killed (zinc.libera.chat (Nickname regained by services))]
vinleod is now known as vdamewood
the_lanetly_052 has quit [Ping timeout: 268 seconds]
the_lanetly_052 has joined #osdev
Brnocrist has quit [Ping timeout: 268 seconds]
bauen1 has quit [Ping timeout: 268 seconds]
poyking16 has joined #osdev
scaleww has joined #osdev
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
bauen1 has joined #osdev
GeDaMo has joined #osdev
scaleww has quit [Quit: Leaving]
socksonme_ has joined #osdev
gdd has quit [Ping timeout: 268 seconds]
gdd has joined #osdev
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
_xor has joined #osdev
heat has joined #osdev
wootehfoot has joined #osdev
vai has joined #osdev
<vai>
Any neat debugging flags for GCC? I have to stop using -W
<vai>
I want to do a warning level that warns of pragmatic errors, really true ones only.
<vai>
aka warnings
<GeDaMo>
Why do you have to stop using -W? Did the parameter police pay you a visit? :|
<psykose>
i think -pedantic has what you're looking for
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
<vai>
yeah, and great to find an error without the warnings settings GeDaMo + psykose ... meaning I have 100 lines of C code
<vai>
*100 thousand
<vai>
FS has errors. And HD driver I am looking now, it still has a remote device server, etc. code I have to remove -- which is completely wrong approach in monolithic kernel.
<vai>
FS is not that bad, I get a ls on my OS.
<vai>
chs.c - nice to have you friend still along
<vai>
#coders is empty eh ?
<GeDaMo>
There's ##programming for general programming chat
wootehfoot has quit [Read error: Connection reset by peer]
<heat>
but in all honesty, like good base "debugging" flags are -O0 and -g
<zid>
-Og
<heat>
-O0 is especially important when using clang
<zid>
-O0 is useless when using gcc
<zid>
it generates utterly trash code that's unreadable
<heat>
-Og is a nop in clang :) and -O1 onwards gives you some fucked up debugging info sometimes
<zid>
-fwhole-program gives the best debug info
<zid>
main.LTO_FRAG_473
<zid>
is your entire program
<heat>
(I can't remember if -Og aliases to -O1 or -O0... maybe -O1?)
<heat>
oh I ranted about that yesterday
<heat>
EDK2's debug GCC builds use LTO for some reason
<zid>
It makes sense though, given it basically destroys the program structure in the name of optimization
<heat>
was trying to trace a crash and found a really flattened entry point with all sorts of crap there and almost no debug info
<heat>
yay?
<zid>
I'm not sure it's a solvable problem
<heat>
it's not
<heat>
just turn it off
<psykose>
it's like cutting people up and putting them back together but expecting them to remain alive
<heat>
anyhow, really good, useful debugging flags that require runtime support are -fsanitize=address (or kernel-address for kernels), -fsanitize=undefined, -fsanitize=memory, -fsanitize=thread(?), -fsanitize=scudo
<heat>
all them sanitizers
<zid>
scudo? isn't that a board game
<heat>
it's also an allocator
<heat>
also, no, that's skudo
<zid>
Oh I was thinking of subuteo
<zid>
or cluedo
<psykose>
scudo doesn't even work on musl they should write better code
<heat>
psykose, none of the sanitizers work on musl, or at least "officially"
nyah has joined #osdev
<j`ey>
yes musl should write better code
<psykose>
address/undefined do
<zid>
nothing works in musl
<psykose>
my favorite musl meme is the chromium partition alloc shim
<mjg>
dafqu's scudo
<mjg>
(i read csudo)
<j`ey>
psykose: theres a musl meme there too? I thought that was just an m1 meme :P
<psykose>
yea
<heat>
mjg, scudo is an allocator that tries to provide more safety while being fast
<heat>
for instance, headers are CRC32'd afaik
<psykose>
the partition alloc init code calls pthread_atfork for some lock-related things
<mjg>
wut
<psykose>
except pthread_atfork calls malloc() on musl, so you get an infinite loop
<psykose>
if you comment it out it works fine though
<heat>
mjg, it's android and fuchsia's default malloc
<j`ey>
nice
<psykose>
yolo
<mjg>
heat: well i would not call android fast :-P
<mjg>
on a more seirous note, i'll check it out
<heat>
you can run it as a sanitizer and as standalone
xenos1984 has quit [Read error: Connection reset by peer]
<heat>
just LD_PRELOAD it afaik
<heat>
i think google ditched some "high perf" allocator for it
<vai>
take a cup of coffee, sit down, relax, and read.. this is going to take a while
<mjg>
don't tell me what to do
<vai>
do we do anything else than read?
<heat>
oh yeah also forgot gwp-asan, which randomly samples your allocations and quarantines them
<heat>
yes i write the codes
<vai>
lots of thinking to do
<kof123>
i deal with the customers so the engineers dont have to. i have people skills
<heat>
ASAN helps you debug UAFs, out of bounds, basically all sorts of bad memory acceses
<heat>
accesses*
<mjg>
except when it is buggy
<heat>
MSAN helps you debug uninitialized memory issue AFAIK (I've never used so...)
<heat>
TSAN is for thread races
<mjg>
freebsd has kmsan ported, but it osmetimes goes crazy and reports utter bs
<heat>
GWP-ASAN and scudo are like very lightweight asans-replacements which are not nearly as effective as asan
<mjg>
not only there was no undef access, the supposed callsite does not make sense (i.e. does not deref any memory)
<heat>
UBSAN is for undefined behavior
<heat>
there's also hwasan which is asan for platforms that support memory tagging
<heat>
s/memory/address/
<heat>
safestack and shadowstack help you not fuck over your stack in the case of stack overflows
<heat>
and that's mainly it?
<heat>
there's also gcov and sancov but those are for tracing
<heat>
oh yeah linux also has kmemleak to detect memory leaks
<heat>
it's crazy, it's a fucking garbage collector-like thing
[itchyjunk] has joined #osdev
<heat>
general newbie kernel tips: map your things with the proper permissions, don't forget to set CR0.WP or your architectural equivalent
<heat>
also build interrupt handlers that don't result in a crash-loop, or at least add exception handlers that just cli;hlt
<heat>
you can use CFI directives to get a pretty stack trace from the exception handling code down to where it crashed, yadda yadda in gdb
<heat>
if you're lacking debug tooling, build it
<mjg>
solaris has ::findleaks in the debugger
<zid>
and use -d nochain in qemu if you don't want the crash to not make sense in my case :p
<mjg>
i don't know how it works though
<heat>
i think any sort of findleaks will need to walk the stacks and the heap for references to objects
<heat>
and mark-and-sweep it
<heat>
i don't see how else you could do it
<zid>
time for breakfast I think heat
<zid>
what are you making
<heat>
it's 1pm zid
<heat>
i've already had breakfast
<zid>
1pm is best time for breakfast if you wake up at noon
<mjg>
i'm way ahead of you
<mjg>
2 pm here
<heat>
chad GMT/BST vs virgin CET/CEST
xenos1984 has joined #osdev
<mjg>
real programmers are asleep at this time anyway
<heat>
the PNW people?
<mjg>
in their respective timezones
<mjg>
you are not a programmer unless you sleep 9-5
* mjg
used to do it
<heat>
9-5?
<mjg>
from 9 am to 5 pm
<heat>
9am to 5pm or 9pm to 5am?
<heat>
cringe
<mjg>
i'm getting too old for that shit though
<heat>
you have to wake up at 5am for that david goggins type of shit
<mjg>
STAY HARD
<mjg>
NOTHING GETS DONE BY BEING A BITCH
<heat>
05:10 run 20KM; 05:40: Write javascript; 06:00: Run 50KM; 06:30: write a new kernel; 07:00: Take some viagra so you can stay hard during the rest of the day
<heat>
true chad pnw programmer
<mjg>
gigachad programmer
<zid>
fine I made my own breakfast
<mjg>
are you breakfastshaming me for not having one?
<zid>
No I am shaming heat for not making me any
<mjg>
OK
<mjg>
please continue
gildasio has joined #osdev
<zid>
I have too much food but I didn't wanna leave like 5% of it in the fridge I'd do nothing of
<zid>
with
<heat>
vai, you can also set up clang-tidy to help you catch issues
gog has joined #osdev
<heat>
oh yeah also fstack-protector
<heat>
or fstack-protector-strong, or fstack-protector-all
<psykose>
one day they'll just pick one
<mjg>
fstack-protector-chad
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
<mrvn>
mjg: most important meal of the night
<mjg>
:)
<mjg>
hm i just wrote a 200 line diff and it compiled the first time
<mjg>
not looking good for it working first time, is it
<GeDaMo>
Even worse, it might /appear/ to work :P
<mjg>
i take it!
srjek has joined #osdev
<mrvn>
That's usually the difference between C and ocaml. C code often compiles the first time but doesn't work. ocaml code doesn't compile the first time. but when it does it usually works.
<mjg>
well it booted
<mjg>
i think that's sufficient testing
SGautam has joined #osdev
wootehfoot has joined #osdev
srjek has quit [Ping timeout: 244 seconds]
poyking16 has quit [Ping timeout: 252 seconds]
poyking16 has joined #osdev
Brnocrist has joined #osdev
poyking16 has quit [Ping timeout: 240 seconds]
poyking16 has joined #osdev
poyking16 has quit [Ping timeout: 245 seconds]
poyking16 has joined #osdev
zhiayang has quit [Quit: oof.]
zhiayang has joined #osdev
poyking16 has quit [Ping timeout: 268 seconds]
poyking16 has joined #osdev
gildasio has quit [Remote host closed the connection]
<bslsk05>
twitter: <Azure_Husky> Here's a common scam that is going around that you should know about:   Sometimes cats will meow at you like they haven't been fed, but in fact someone DID feed them and they're just trying to get fed again
<gog>
zid: meoww
<zid>
Don't listen to her lies
<sbalmos>
woof
matt__ has quit [Read error: Connection reset by peer]
<bslsk05>
en.wikipedia.org: The Midnight Sun (The Twilight Zone) - Wikipedia
poyking16 has quit [Quit: WeeChat 3.6]
the_lanetly_052 has quit [Ping timeout: 240 seconds]
gildasio has joined #osdev
sprock has quit [Ping timeout: 268 seconds]
bauen1 has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
matt__ has joined #osdev
gildasio has quit [Remote host closed the connection]
dh` has quit [Quit: brb]
gildasio has joined #osdev
dh` has joined #osdev
sprock has joined #osdev
dh` has quit [Ping timeout: 245 seconds]
Vercas6 has quit [Remote host closed the connection]
gxt___ has quit [Remote host closed the connection]
Vercas6 has joined #osdev
gxt___ has joined #osdev
wootehfoot has quit [Quit: Leaving]
matt__ is now known as freakazoid333
GeDaMo has quit [Quit: A program is just a bunch of functions in a trenchcoat.]
wootehfoot has joined #osdev
SGautam has quit [Quit: Connection closed for inactivity]
gxt___ has quit [Ping timeout: 268 seconds]
gxt___ has joined #osdev
gxt___ has quit [Remote host closed the connection]
gxt___ has joined #osdev
bauen1 has quit [Ping timeout: 252 seconds]
gog has quit [Read error: Connection reset by peer]
bauen1 has joined #osdev
poyking16 has joined #osdev
poyking16 has quit [Client Quit]
gog` has joined #osdev
gog` is now known as gog
<heat>
geist, why is fuchsia's arm64 trap code so confusing?
<zid>
working as intended, it caught heat
<heat>
it seems to have a whole lot of paths
<heat>
I would expect the basic path to be: switch stacks (?), save registers, branch to C++, load registers, switch stacks, eret
<heat>
(right now it's unclear to me where that switch stacks step is done)
<Griwes>
Hmm, I think I need to actually write process and thread teardown code to proceed with what I've been doing. I've been putting this off for a while now :'D
socksonme_ has quit [Ping timeout: 245 seconds]
<mjg>
hrm is there an amd64 cpu which does not support sse3?
<heat>
yes
<heat>
it's not a base ISA feature
<mjg>
:sadface:
<heat>
sadge
<heat>
you know what also isn't but is way cooler?
<heat>
tlbsync and invlpgb
<heat>
who tf needs sse3 after that
<zid>
I'm not sure if you can *find* one of those cpus
<zid>
but in theory they are allowed
<zid>
like, `core` only existed in a few thousand laptops total
<zid>
before core2 replaced it and sold hundreds of millions of chips
<zid>
but we have to make allowances for it
<heat>
and the k8 too
<zid>
I thought k8 was at least popular
<zid>
the x2 and fx and sempron and opteron and turion were all k8 weren't they
<heat>
possibly
<heat>
just adding it as one of the sse3-less cpus
<heat>
at least according to gcc
<zid>
yea amd is built different
<zid>
aka since 3dnow intel has added all the simd extensions first and amd has gotten them later
<heat>
3dnow is amd's mmx but worse
<heat>
since at least mmx is used once during boot
<zid>
I've never used or seen 3dnow :(
nyah has quit [Quit: leaving]
<mjg>
3dbie
<mjg>
3dbye even
dh` has joined #osdev
<heat>
3dlater
carbonfiber has joined #osdev
<geist>
heat: i think it needs a bit of a cleanup (re: the arm64 dispatch path) but the primary reason is the N entry points, and trying to optimize them individually
<geist>
hence lots of macros that stamp out things
<geist>
and then there's a fastpath for teh syscall mechanism, which is also mostly implemented in the exceptions.S code
<geist>
i have a TODO to go in there and say fuck it with the whole 'try to fit the first part of the exception handler in the 0x80 bytes you get per exception
<geist>
and just build a table that branches to the real implementations
leah_ has joined #osdev
<geist>
that will reduce some of the confusion, at the expense of not fully utilizing the space in the exception table
<geist>
that seems to be what most Big OSes do
<carbonfiber>
Is the default PIO mode for devices specified anywhere? I can't find it in the ATA standard. How is a host able to use the Identify Device command if there isn't a default PIO mode specified in the standard?
<geist>
heat: but yeah you have identified that the complexity has reached a point as to make it hard to read
<geist>
also FWIW a lot of the complexium has to deal with only reloading some regs some times (x18, x20, etc) and dealing with debug instrumentation
<geist>
heat: re: switching stacks zircon currently uses the SP_ELx mode, so there's no real stack switching necessarily. before you exit you simply restore SP_EL0 before eretting
<bslsk05>
fuchsia.googlesource.com: zircon/kernel/arch/arm64/exceptions.S - fuchsia - Git at Google
<geist>
i think the regsave/regrestore macros are fairly easy to follow, its precisely where they get stamped out and how many instances of it is the complexity
froggey has joined #osdev
dude12312414 has joined #osdev
dequbed has quit [Quit: bye!]
dequbed has joined #osdev
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
opal has quit [Write error: Connection reset by peer]
Vercas6 has quit [Read error: Connection reset by peer]
dude12312414 has quit [Write error: Connection reset by peer]
gildasio has quit [Write error: Connection reset by peer]
opal has joined #osdev
dude12312414 has joined #osdev
gildasio has joined #osdev
Vercas6 has joined #osdev
<heat>
geist, yeah
<heat>
probably a good chunk of me not being able to read it is that I'm still learning how arm64 works
<heat>
but it definitely seems confusing anyway
<heat>
what's x20 for? safestack or so?
<heat>
ah SP_EL0 is cool
<heat>
what exactly do I need to save? x0-31, sp, pc, pstate
<heat>
am I missing something?
<heat>
this looks like a reasonable stack frame but linux has something way more complex, as usual
<heat>
linux doesn't seem to agree but who the fuck am I to be able to understand this
<heat>
as an aside, something I've never really understood in linux is the orig_eax/orig_x0/... whatever ordeal
<geist>
that's *probably* so that they can restart a syscall
<geist>
even if they've already modified the return rax or whatnot
<geist>
what part of it doesn't seem to agree?
<heat>
they have different members in the struct
<geist>
they have some additional things, presumably for their purposes, but the base stuff is the same
<geist>
just different names
<heat>
ah I think I see it
<heat>
lr and usp are just x[] registers
<heat>
elr is pc
<geist>
lr is x30 yes, usp is a special case
<heat>
spsr is pstatus
<geist>
elr is pc, spsr.. yep
<geist>
er yeah lr is elr
<geist>
right
<heat>
isn't usp that register that is both xzr and sp?
<geist>
kinda but that's just an encoding
<geist>
SP is a special register
<heat>
why?
<geist>
because it is
<heat>
because of the alignment requirements and whatnot?
<geist>
architectural decisions with arm64
<geist>
they decided to make it a special case
<heat>
special case of what?
<geist>
presumably much easier to build as a high performance design if its not a general purpose register
<geist>
special case as in it's not part of the normal register set
wootehfoot has quit [Quit: Leaving]
<geist>
and you can't do all normal operations against it
<heat>
ah yeah sure
<geist>
in certain cases it's *encoded* as the same as xzr
<geist>
but that's an implementatino detail of the ISA encoding
<geist>
both PC and SP being non regular integer registers is one of the key differences between arm32 and arm64
<geist>
primarly to make the design simpler. PC being a normal register in arm32 is really nifty but its hard to build high speed superscalar designs out of that, so i have read
<heat>
why?
<geist>
less special cases
<heat>
why isn't mov $func, %pc just a jmp?
<geist>
it is. it was, in arm32
<geist>
but now that means the decoder has to look for that, and you can do lots of more exotic ways to get a branch out of the ISA
<geist>
so it's harder to find and decode all those special cases
<geist>
much simpler if there's effectively one or two ways to branch, makes the branch predictors life far simpler