dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
nyah has quit [Ping timeout: 252 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
eck has quit [*.net *.split]
IRChatter has quit [*.net *.split]
IRChatter has joined #osdev
eck has joined #osdev
smach has joined #osdev
heat has quit [Ping timeout: 246 seconds]
[itchyjunk] has quit [Remote host closed the connection]
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
carbonfiber has quit [Quit: Connection closed for inactivity]
SpikeHeron has joined #osdev
vdamewood has joined #osdev
Guest5920 has joined #osdev
wand has quit [Remote host closed the connection]
scoobydoo_ has joined #osdev
scoobydoo has quit [Ping timeout: 252 seconds]
scoobydoo_ is now known as scoobydoo
scoobydoo_ has joined #osdev
scoobydoo has quit [Ping timeout: 252 seconds]
scoobydoo_ is now known as scoobydoo
wand has joined #osdev
fatal1ty has joined #osdev
garineko has quit [Quit: Connection closed for inactivity]
wand has quit [Ping timeout: 258 seconds]
scoobydoo has quit [Ping timeout: 252 seconds]
scoobydoo has joined #osdev
wand has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
scoobydoo has quit [Ping timeout: 260 seconds]
scoobydoo has joined #osdev
scoobydoo has quit [Ping timeout: 246 seconds]
scoobydoo has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
nyah has joined #osdev
nyah has quit [Quit: leaving]
Burgundy has joined #osdev
crm has joined #osdev
orthoplex64 has quit [Ping timeout: 272 seconds]
CompanionCube has quit [Ping timeout: 248 seconds]
CompanionCube has joined #osdev
identitas has quit [Quit: Bridge terminating on SIGTERM]
Irvise_ has quit [Quit: Bridge terminating on SIGTERM]
chibill has quit [Quit: Bridge terminating on SIGTERM]
Maja[m] has quit [Quit: Bridge terminating on SIGTERM]
Maja[m] has joined #osdev
terminalpusher has joined #osdev
identitas has joined #osdev
chibill has joined #osdev
Irvise_ has joined #osdev
awita has joined #osdev
Burgundy has quit [Ping timeout: 252 seconds]
GeDaMo has joined #osdev
lg is now known as notwhonorttiwant
notwhonorttiwant is now known as lg
tomaw has quit [Quit: Quitting]
tomaw_ has joined #osdev
tomaw_ has quit [Client Quit]
awita has quit [Remote host closed the connection]
tomaw has joined #osdev
Burgundy has joined #osdev
darkstardevx has quit [Remote host closed the connection]
pretty_dumm_guy has joined #osdev
darkstardevx has joined #osdev
Celelibi has quit [Ping timeout: 246 seconds]
Celelibi has joined #osdev
axis9 has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
SGautam has joined #osdev
lanodan has quit [Ping timeout: 264 seconds]
lanodan has joined #osdev
bauen1 has quit [Ping timeout: 272 seconds]
bauen1 has joined #osdev
sortie has quit [Ping timeout: 272 seconds]
poyking16 has joined #osdev
sortie has joined #osdev
axis9 has quit [Read error: Connection reset by peer]
terminalpusher has quit [Remote host closed the connection]
epony has quit [Quit: QUIT]
axis9 has joined #osdev
axis9 has quit [Read error: Connection reset by peer]
xvmt has quit [Remote host closed the connection]
xvmt has joined #osdev
archenoth has joined #osdev
SpikeHeron has quit [Quit: WeeChat 3.7]
axis9 has joined #osdev
heat has joined #osdev
KaitoDaumoto has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat_ has joined #osdev
Burgundy has left #osdev [#osdev]
Burgundy has joined #osdev
axis9 has quit [Remote host closed the connection]
heat_ is now known as heat
epony has joined #osdev
fatal1ty has quit [Ping timeout: 255 seconds]
wootehfoot has joined #osdev
<marshmallow>
I have a doubt. do for each process exist both page tables recording the translation from virtual to physical addresses, and also page tables containing the related mm_struct of that process?
gildasio has quit [Remote host closed the connection]
wand has quit [Ping timeout: 258 seconds]
gildasio has joined #osdev
nvmd has joined #osdev
SpikeHeron has joined #osdev
wand has joined #osdev
SGautam has quit [Quit: Connection closed for inactivity]
smach has quit [Ping timeout: 246 seconds]
<heat>
what do you mean with page tables containing the mm_struct
Burgundy has quit [Remote host closed the connection]
Burgundy has joined #osdev
<marshmallow>
like, where does exactly mm_struct of each process live?
<marshmallow>
kernel's page tables?
<heat>
ok so mm_struct is kernel memory
<heat>
but kernel memory /usually/ lives in every process' page tables
<heat>
imagine you're dividing the address space 50/50, and the top page table has 4 entries; the bottom 2 are for user stuff, and the rest is always mapped/reserved for the kernel
<clever>
until cpu bugs force you to not do that
<heat>
this is the simple design
<heat>
yes
<heat>
meltdown et al made KPTI
<heat>
that has some trickery and now there's a shadow page table for each process (with user + kernel mapped) and the user page table which has user + trampoline
<heat>
that trampoline deals with switching to the real page tables
<clever>
does x86 have seperate pointers to the user and kernel tables? (pre meltdown)
<heat>
no
<heat>
never had
<marshmallow>
alright, and what exactly does it mean that kernel unmaps its address space when returning to EL0/ring3?
<heat>
probably never will
<clever>
ah, thats one region where i can see arm as being better, TTBR0/TTBR1
<heat>
it doesn't unmap anything
<marshmallow>
are kernel page tables still there?
<clever>
yes
<clever>
there is a bit in the tables, saying if its user or kernel memory
<heat>
idk are you talking about meltdown mitigations or what?
<marshmallow>
heat: spectre/meltdown mitigations on arm64, yes
<heat>
KPTI would make you switch back to the user address space
<clever>
heat: arm has (almost) always had 2 registers for the root of the paging tables, one for the lower half, one for the upper half
<heat>
on arm64 I assume they have a dummy TTBR1 with the trampoline mapped
<clever>
heat: so you dont need to keep a copy of the kernel mappings in every user table
<heat>
and "unmapping the kernel" means switching to that trampoline
<heat>
that sounds reasonable
<clever>
ah, that
<marshmallow>
sorry, in what sense "for the root of the paging tables, one for the lower half, one for the upper half"?
<heat>
but im not particularly aware of how arm64 does this
<marshmallow>
where do the lower and upper point to?
<clever>
marshmallow: TTBR0 has the addr of the "userland" paging tables, that start at virtual addr 0
<clever>
marshmallow: TTBR1 has the addr of the "kernel" paging tables, that end at INT_MAX virtual
<clever>
the size of both, is set by another pair of registers
<bslsk05>
forums.raspberrypi.com: Understanding of mmu TCR.txsz - Raspberry Pi Forums
<clever>
a recent answer in here explains it
heat has quit [Remote host closed the connection]
<marshmallow>
thanks! and so there's no trampoline at all in arm64?
<clever>
marshmallow: you can still add your own if you want to fight meltdown style bugs
heat has joined #osdev
<clever>
where TTBR1 only maps the trampoline code, and swaps TTBR1
<heat>
clever, you mean ULONG_MAX btw
<heat>
ofc there's a trampoline
<marshmallow>
clever: but from the userland perspective it shouldn't matter (both in pre/post meltdown) as kernel page tables are not accessible, no?
<clever>
marshmallow: correct
<heat>
incorrect
<heat>
post meltdown would leak kernel data and addresses
<heat>
that's why this happened
<marshmallow>
on arm64 too?
<clever>
i am assuming normal operation, nobody is trying to exploit it
<heat>
yes, on arm64 too
<clever>
a non-malicious userland will never notice the difference
<marshmallow>
and so, sorry, how does arm64 actually mitigate this?
<heat>
by replacing the normal kernel TTBR1 with a dummy one that only has the trampoline mapped
axis9 has joined #osdev
<marshmallow>
and what does the trampoline do/contain?
<heat>
code and data needed to switch to the normal kernel evironment
<clever>
marshmallow: code that changes the TTBR1 and flushes the TLB, which should be mapped in both the real kernel and the fake trampoline kernel
<clever>
and likely code to support the reverse as well
<marshmallow>
and this however comes with a detrimental of performance, right?
<clever>
and probably the irq table too, since the trampoline TTBR1 will be mapped when the cpu tries to handle an irq
<clever>
yep
<heat>
yes
<clever>
all of that TLB flushing ruins the cache, and your injecting an extra dozen opcodes into every syscall and irq
<clever>
if your cpu core has hw mitigations, you can skip the trampoline
<clever>
if you control/trust the userland code, skip it
<heat>
they probably play some games with ASIDs to skip some tlb flushing
<clever>
heat: i was thinking the same, but i'm not sure if thats user, kernel, or both
<marshmallow>
got it. and how/when can TTBR0 and TTBR1 possibly change? can they be seen as the equivalent of CR3 in x86_64? does TTBR0 change at each process context switch?
<heat>
when switching address spaces yeah
<clever>
the original idea (pre meltdown), is that you only change TTBR0 on context switch, and TTBR1 never changes
<heat>
yes they (together) are the equivalent of cr3
<clever>
so you dont have to duplicate the kernel half of the paging tables, in every set of tables
<heat>
you also get 1 more bit of addressing
<marshmallow>
alright, so TTBR0 is set by the kernel to point to the page table directory when switching between processes, right?
<clever>
heat: let me see what the armv8 docs say about ASID...
<clever>
marshmallow: yeah
<marshmallow>
with current->mm_struct->pgd?
<heat>
maybe
<heat>
we're not linux devs
<marshmallow>
sorry how many level of page tables arm64 has?
<heat>
tough question
<heat>
usually 4
<heat>
i think
<heat>
arm64 mmu is stupid configurable
<clever>
at each level, you can just say "this is the end" and give a pointer to a crazy big page, rather then another table
<heat>
i think the traditional "desktop/server" thing is 4KiB pages, 4 levels
<heat>
i've heard android goes smaller sometimes
<marshmallow>
so, to recap, when the kernel needs to translate a virtual address to a physical address, it can achieve so by walking page tables via TTBR0, till the value set by TTBCR?
<clever>
heat: oh, now that i think of it, when transfering from the trampoline to the real kernel, your not unmapping any pages, so do you even have to TLB flush in that case? can the TLB hold unmapped addresses?
<clever>
marshmallow: there is a dedicated opcode in arm to do that translation for you, and if you just do a read/write to an addr, the cpu does everything automatically
<heat>
you shouldn't have to flush when switching to the kernel in arm64's case
<heat>
the new page tables are a superset of the old tables
<heat>
only when going back
<clever>
yeah, thats what i was thinking
<clever>
the flush is only needed when unmapping pages
<clever>
or changing the mapping of a page
<heat>
you need to flush when switching back to the trampoline pts
<heat>
or ASIDs ofc
<clever>
yeah, because your unmapping all of the sensitive bits of the kernel
<clever>
> For these stage 1 translations, each of TTBR0_ELx and TTBR1_ELx has a valid ASID field, and
<clever>
> TCR_ELx.A1 determines which of these holds the current ASID.
<heat>
and ofc global mappings are forbidden in KPTI
<clever>
heat: aha, the ASID and the phys addr of the paging tables, are BOTH in TTBR0/1!
<heat>
yeah
<clever>
so changing TTBR1 swaps both the addr and ASID at the same time
<heat>
just like cr3
<clever>
but there are 2 ASID's, in TTBR0 and TTBR1, and the TCR_ELx.A1 bit says which one is used
<clever>
so you can wind up with some things being tagged to the kernel, or user, depending on A1
axis9 has quit [Remote host closed the connection]
<clever>
that seems a bit odd to me
<clever>
if its using the TTBR0 ASID in kernel mode, then the kernel can have TLB misses, for data it was just using in another proc
<heat>
presumably that makes your TTBRs switchable
<clever>
but if the kernel uses the TTBR1 ASID while doing a read from a user pointer, that lands in the kernel TLB, and could return the wrong answer in another process
<heat>
which makes sense
<heat>
as in, you can have your kernel in 0, user in 1
<heat>
that's not an issue
<heat>
how is a user pointer the same as a kernel one?
<heat>
AIUI you'll still use the same "64-bits" to index in the TLB
<clever>
what i mean, is if the kernel reads from user memory while in pid 2
<clever>
then it context-switches to pid 3, and reads the same user pointer, but now with a different TTBR0
<clever>
it should respect the new tables, and not use the old TLB entry
<heat>
your ASID should have switched
<clever>
so that means the kernel should be using the TTBR0 ASID
<heat>
user pointer -> TTBR0 -> ASID y instead of x -> lookup_tlb(user_ptr, y)
<clever>
but now all of your kernel pages, are isolated to the userland TLB ASID
<heat>
hm?
<clever>
and when you context switch, all of the kernel memory has a TLB miss, because its looking in the wrong ASID
<heat>
hm2
<clever>
because while arm64 has 2 ASID's, you have to manually select which one is active, via the TCR_ELx.A1 bit
<heat>
ok
<heat>
where's the problem?
<heat>
you obviously set it to the TTBR that changes and is thus using the ASID
<clever>
while running in kernel mode, which ASID should be active?
<heat>
hmmmmm
<heat>
i think i'm starting to see your point
wand has quit [Ping timeout: 258 seconds]
<heat>
the easy, non-meltdown solution would be to use TTBR0.ASID and have the kernel mapped as global
<clever>
but now the kernel will TLB miss every time you context switch, because the kernel lookups are landing in the userland ASID
<clever>
if i'm understanding this doc right
<heat>
but they're globals
<heat>
globals are not pinned to ASIDs
<clever>
ah, is that a special flag in the table entry?
wand has joined #osdev
<heat>
yes
<clever>
i see it now, the nG bit
<clever>
that solves that mystery, for the non-meltdown case, you can just always use the TTBR0.ASID, and leave the kernel global
<clever>
but i'm not sure how you could use the ASID to help with a trampiline
axis9 has joined #osdev
Vercas6 has quit [Ping timeout: 258 seconds]
[itchyjunk] has joined #osdev
Vercas6 has joined #osdev
axis9 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
<pbx>
what is the accepted solution for accessing misaligned ints these days?
<heat>
memcpy
<pbx>
manually writing a function that uses uint8_t loads and shifts, or is there some intrinsic
<heat>
memcpies get optimized out
<mjg_>
__builtin_memcpy is the intrinsic :-P
poyking16 has quit [Quit: WeeChat 3.5]
<mjg_>
provided the size is known at comiplation time
poyking16 has joined #osdev
crm is now known as orthoplex64
wand has quit [Remote host closed the connection]
xenos1984 has quit [Ping timeout: 246 seconds]
xenos1984 has joined #osdev
wand has joined #osdev
<sham1>
And the smart compiler can turn your normal memcpy into that with known sizes and optimise it away
<sham1>
So don't rely on undefined behaviour: read your data properly
axis9 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
elastic_dog has quit [Ping timeout: 246 seconds]
elastic_dog has joined #osdev
epony has quit [Quit: QUIT]
gog has joined #osdev
<gog>
mew
<heat>
meooooooooooooooooooo
<heat>
w
<sham1>
mow
<heat>
momw
xenos1984 has quit [Ping timeout: 252 seconds]
bauen1 has quit [Ping timeout: 260 seconds]
bauen1 has joined #osdev
SGautam has joined #osdev
axis9 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
axis9 has joined #osdev
nvmd has joined #osdev
joe9 has quit [Quit: leaving]
gmodena has quit [Ping timeout: 268 seconds]
wand has quit [Remote host closed the connection]
xenos1984 has quit [Ping timeout: 255 seconds]
<heat>
pbx, does xinit show a blank screen unless xterm is present?
<heat>
cuz i have a blank screen
<mrvn>
heat: xinit usually tries a few things with xterm being the last fallback
<mrvn>
any menues when you press a mouse button?
<heat>
i don't have input yet
<j`ey>
heat: time to port xterm
<mrvn>
some WMs don't have any icons and without config to also start an xterm you just have the WM running
<mrvn>
ps aux
<mrvn>
look what's running
<heat>
im talking about my os
<mrvn>
.oO(time to implement ps)
<heat>
X is running, so is xinit (through startx)
<j`ey>
do you have strace?
<heat>
complicated question
<j`ey>
/ put a printf in 'exec*' syscall :P
<heat>
tldr yesish
<mrvn>
you must have some WM or app that startx has found that keeps the X running
<heat>
i probably need ERESTARTSYS support
<axis9>
yes
brynet has quit [Quit: leaving]
xenos1984 has joined #osdev
wand has joined #osdev
<mrvn>
Has anyone implemented X? How much of X do you need to run everyday apps? I'm pretty sure you don't need stippled eplisoid segments with rounded corners. But what do you need?
<pbx>
heat: i've not tried xinit
<pbx>
just starting the server by hand
<pbx>
try -retro on the server to get the classic background pattern and an X cursor
<heat>
hm
<mrvn>
pbx: Just "X" will just show the default background
<heat>
Xorg -retro just works?
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<mrvn>
for some form of "works". you need another shell/terminal to then start some app on the display
<bslsk05>
en.wikipedia.org: Common Desktop Environment - Wikipedia
<mjg_>
no
<heat>
zid, something b e y o n d y o u r u n d e r s t a n d i n g
<mjg_>
there was this turbo unusuable window manager
<mrvn>
close, so close
<zid>
yes yes it is
<mjg_>
lemme look for it
<heat>
i'm relatively sure it started out as osdev-offtopic
<zid>
yea the lusers look similar
<heat>
anyway bslsk05 is theirs for instance
<mjg_>
maybe cwm
<shikhin>
Oh I see.
<pbx>
mrvn: no longer, default now is black bg with no cursor
<mjg_>
now i remember
<mjg_>
heat: twm
<mjg_>
> twm is a window manager for the X Window System. Started in 1987 by Tom LaStrange, it has been the standard window manager for the X Window System since version X11R4.
<mjg_>
utter crap
<heat>
LaStrange
<heat>
hehehehehe
<mjg_>
used to be the default on openbsd
<pbx>
fvwm2 is decent for something that doesn't require a full toolkit
<j`ey>
fvwm2 is a cool retro look
<mjg_>
team i3 right here, but i don't know the deps
* pbx
cries in having to use fvwm for work every day
<mjg_>
wut?
<zid>
xfce4 has the nicest terminal so I just install xfce4-meta
<zid>
and be done with it
<mjg_>
you stuck on some old unix workstation? :P
<pbx>
mjg_: nah, VNC into the real computers
<pbx>
i guess we have plasma too, but you really don't wanna try that on VNC over vpn
<j`ey>
my coworker uses fvwm2.. locally out of choice :P
<pbx>
honestly fvwm is fine, it's the xterm default that kills me
<bslsk05>
github.com: darwin-xnu/proc_reg.h at main · apple/darwin-xnu · GitHub
<marshmallow>
(/cc clever too)
<pbx>
i'm too used to the Ctrl-Shift-{C,V,X} keybinds
<heat>
marshmallow, woah that's so fucking clever
<marshmallow>
so basically the kernel address space is mapped to the user's one, when running userspace applications, but it contains only a small subset of it (w/ just the exception vector?)
<heat>
yes
<heat>
they contract and expand the TTBR1 address space when switching to and from EL0
<heat>
Only In Arm64 moments
<mrvn>
marshmallow: not having all of the kernel mapped in user space is a security mitigation against speculative execution exploits
SpikeHeron has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
<heat>
yeah im porting xterm now
<heat>
this is the shittiest port experience but god dang it im doing it
<j`ey>
have you had to patch much?
<heat>
config.sub, libtool patches in every autoconf package
* heat
exhales
<heat>
MESON BEST
<heat>
and i'm adding features to make Xorg work, which obviously means they're not correct
<heat>
like my unix sockets
<pbx>
you don't need those per se
<heat>
yeah
<heat>
but you should
<pbx>
assuming you have AF_INET
Guest5920 has quit [Quit: WeeChat 2.8]
terminalpusher has joined #osdev
vin has joined #osdev
<marshmallow>
heat: not completely clear though about one thing: what isn't eventually flushed in the TLB?
<bslsk05>
github.com: darwin-xnu/proc_reg.h at main · apple/darwin-xnu · GitHub
<heat>
if the kernel mappings are in ASID y and the user mappings are in ASID x, you don't need to invalidate all the kernel mappings when going back to user-space
netbsduser has joined #osdev
terminalpusher has quit [Remote host closed the connection]
gorgonical has joined #osdev
<gorgonical>
Okay guys just to make sure I'm not dumb: a 16550 in fifo mode will continually push bytes to the front, right?
<gorgonical>
As in you repeatedly do a lb intsruction from the register address?
<gorgonical>
And you know you are done when the status register says rxfifo empty, or so
<geist>
depends on what you mean by front, but if you mean at the tail end of the fifo yes
<geist>
if it's full and you keep pushing i dont think that's well defined
<gorgonical>
I mean let's say you've got 8 bytes and the rx reg is 0x0 offset. You just do lb x0, (base+0x0) 8 times, then right?
brynet has joined #osdev
<geist>
to read 8 bytes out of the fifo? yes
<gorgonical>
Right. The hardware manages the fifo to always present the "next" byte at 0x0
<geist>
internally it'll read you the head of the fifo until it's empty in which case it returns UNDEFINED
<geist>
right
<gorgonical>
right
<gorgonical>
my risc-v forth is coming along and I'm having to build a uart driver
<geist>
yeah okay, i reread your original statement. this is for the RX path yes
<geist>
what's unforunate is the 16550 isn't verygood at giving you exactly all the signals you want, but i think you get the bare minimum: the rx fifo has something in it
<geist>
or the equivalent: the rx fifo is empty
<geist>
so you pop stuff until the status changes
<gorgonical>
yeah at this point I'm doing extremely simple signalling. I think my first try will be no-int
<gorgonical>
I guess tx will come soon enough too
<geist>
'better' uarts with better fifos have a counter that tells you precisely how much is in it, which is more convenient since you can just in a loop read that many bytes out before checking again
<geist>
yah the TX side of the 16550 is annoying too. i think it only tells you if the fifo is empty, but not how much is in it
<heat>
geist, did you read the convo about meltdown? i'm kinda unsure how you can avoid losing all of the kernel's TLB entries when switching address spaces
<geist>
so you can't know necessarily where it is at if you have stuffed in a few bytes and it hasn't finished transmitting them
<gog>
what about ASID or PGE? or can you not use those with meltdown?
<gorgonical>
so the only "safe" approach is 1 byte, poll until empty, repeat
<gorgonical>
lol
<geist>
heat: with KPTI i think you have to dump the kernels TLB yes. global mappings are my understanding verboten
<gog>
oof
<heat>
:((
<gorgonical>
even with asid?
<geist>
but, if you have PCID/ASID i think that mitigates it a lot
<heat>
you use ASID for kernel <-> user switches
<geist>
as in the kernel gets to be a new asid
<heat>
there's no way to tell the CPU that ASID 1 and ASID 2 share pages
<geist>
there's a window of x86 implementations iirc where the PCID isn't useful for it so you hae to dump everything
<geist>
and then on very new cpus you dont need the KPTI
<geist>
so i think in the end this will all just be some Dark Era of cpus where the mid 2000s stuff was just bad
<geist>
and newer stuff you dont have to do this anymore
<gog>
until there's a new cache timing attack
<geist>
sure, but whether or not you need KPTI is the question
<geist>
i think there will always be spectre style stuff
<geist>
but whether or not you need to keep the kernel isolated i dunno. i hope now
<geist>
not
<heat>
linux people were revisiting the idea of isolating user and kernel completely
<heat>
and only mapping user mappings in copy_to_user et al
<geist>
i think on many arches it's not so bad. POWER/PPC i think historically was basically always set up for that
<geist>
a whole lot of this is to due with the x86 centricness of the world. it's a trash fire, so all solutions are hard and complex (and interseting)
<geist>
that being said ARM64 has one fatal flaw in this, and i dont think they solved it in v9. i have no idea why
<geist>
when you have an ASID you can only assign it to one of the two active page tables
<gog>
yeah didn't arm64 have a cache timing attack similar to meltdown?
<geist>
i dont know why you can't do both
<geist>
so you cant just independently put the kernel and user space in two different asids. by definition one of the two is always running with asids off
axis9 has quit [Remote host closed the connection]
<geist>
(which i think is functionally the equivalent to using ASID=0)
gorgonical has quit [Ping timeout: 260 seconds]
<geist>
but take what i wrote with a grain of salt. i haven't personally climbed this particular tech tree of KPTI solutions
<geist>
i read a bit about it, sort of grokked it a while back, but havne't actually *done* it
<geist>
so there are probably things i'm completely missing
<gog>
but you're the closest thing to a kernel master we have
gorgonical_ has joined #osdev
<geist>
even within that bucket there are things i know about and things i've personally done. the latter i have a lot more confidence in
<gog>
fair
<geist>
soeaking of low confidence i was fixing some bugs in the x86 mmu implementations (32 and 64) in LK last night. omg it's worse than i thought
<geist>
totally full of bugs. i see why we rewrote it in fuchsia
<gog>
lol
<geist>
it was some code that was originally submitted by intel. and it's got a really insidious set of bugs. lots of really really loosey goosey interpretation of what is physical and virtual
<geist>
everything is just stored in uint64s so sometimes it's passing around pointers, sometimes physical addresses, and sometimes it's a page table entry with the bits masked off and sometimes now
<geist>
so full of bugs
<gog>
and somebody at intel wrote this
<gog>
XD
<geist>
yah at the time LK didn't really have an x86 port so i basically took it as 'whelp this is better than nothing'
<geist>
a mistake hopefully i'll learn from
<gog>
yes. never trust code from intel
<geist>
it's code that *looks good* but totally once you try to figure it out turns out is fully of bugs. that's where i was fixiing the inline asm with the rep ins instruction the other day. also from intel
<geist>
i mean good for them for submitting code. i approve of this practice
<geist>
but... i'll have to be more careful
<gog>
yes
<heat>
what bugs did you find
<heat>
how many bugs can you fit in a low level mmu really?
<heat>
s/mmu/mmu code/
<geist>
also annoying thing i hate about lots of x86 mmu implementations: insists on having parallel routines and whantot for every level of the 4 page tables
gorgonical_ has quit [Read error: Connection reset by peer]
<geist>
ie, a function to deal with pdpe, pml4, pdp, etc
<heat>
UGH
<geist>
like, just treat it as 4 levels of page table, quit calling it separate stuff
<geist>
so tons of copy pasta with one thing changed, etc
<heat>
but they're also not quite similar
<geist>
sure they are, just a few tweaks here or there
<heat>
some bits' meanings change in a few levels
<geist>
this is true, but it's still better IMO to have routines like 'frob this level(uint level)' and then logic inside
<geist>
that way you still get one code path
<heat>
yeah
<gog>
that's how some of my code works
<geist>
but with page tables there's always the eternal question: do you recursively walk down via having the walk routines call itself with level - 1, or do you try to walk the PTs in a loop
<geist>
some algos work better for one or the other
<heat>
level += 1;
<gog>
loop
<geist>
but in general the recursive walk is more powerful
<geist>
the big function that's so full of bugs is the x86_mmu_get_entry i think
<geist>
it turns out to be just totally broken
<geist>
basically i was finally getting around to really unit testing the arch mmu code for the 5 mmu implementations in LK (riscv, arm32, arm64, x86-32, x86-64) and finding the x86 ones were really bad
<bslsk05>
github.com: lk/mmu.cpp at master · littlekernel/lk · GitHub
<heat>
i have a pattern in my mmu code where it's just <arch>_mmu_get_pt_entry()
<geist>
could return some sort of argument to the opcode that says 'check if PT is zero and free it' maybe
<heat>
you give it a virtual address, and it gives you a pointer to the pte
<geist>
yah that's a pretty clean, if limited, design
<heat>
it's maybe too simple, but simple
<pbx>
with TCP how do you prevent exhausting your TX window on both sides? I'm imagining a situation where after habn
<geist>
another strategy that might work is extend it to return an array of pointers to all the PTs leading to the entry
<pbx>
handshake, both parties send winsz bytes
<pbx>
and now can't ack because window exhausted
<geist>
so that the code that gets it has an opportunity to do more work, like free upper page table entries
<heat>
ACK doesn't use the window AFAIK
<heat>
geist, oh yeah i also have that
<geist>
right, ACKs are metadata in TCP packet, not a byte
<heat>
my mmu code is kind of chaotic
<geist>
so you can send a zero byte packet with an ACK in it
<heat>
my x86 code evolved over 7 years, so lots of different ideas
<pbx>
i thought set flags also added 1 to the byte count
<heat>
and riscv is x86 copied and patched, arm64 is copied from riscv and patched
<geist>
no, SYN uses a byte count, which is a bit strange but for a reason
<pbx>
ah, nvm then :)
<heat>
seq doesn't exactly correlate to window size
<geist>
heat: yeah that's why i think of all the strategies, the recursive walk actually is the most powerful, because it gives you the best opportunity to clean up on the way out (like check upper PTs for zeroing)
<geist>
and it allows to keep walking from the same level it was already at, or bounce up a level and go to the next PT, etc
<bslsk05>
github.com: Onyx/mmu.cpp at master · heatd/Onyx · GitHub
<geist>
but i think it tends to be the most complex
<heat>
i kinda have that as well
<geist>
yah the arm64 code in LK does it that way
<heat>
it was a bitch to write
<geist>
exactly
<geist>
tends to have to be rewritten for each of the higher level algorithms (map, unmap, query, change protection) since they have slightly different constraints
<geist>
also when you get into large page entries that get split that always really throws a spanner in
Lumia has joined #osdev
jafarlihi has joined #osdev
<jafarlihi>
I want to directly boot to 64 bit, should I go with Limine or BOOTBOOT?
<geist>
on what architecture?
<jafarlihi>
x86
<geist>
good question. i dont personally know either of those. is the intent to avoid having to write 32 to 64bit?
<geist>
UEFI is not part of the question?
<jafarlihi>
No UEFI, don't want to write 32 to 64 code myself
<geist>
gotcha. i dont know those projects, so i can't help, but i can help you write 32 to 64. it's not difficult at all
<j`ey>
limine seems pretty popular now
<geist>
and most of what you have to do to get to 64bit you have to do eventually (ie, set up your own GDT, your own IDT, your own page tables) so in the long run it doesn't save you too much
<geist>
but if you wanna get running now, SGTM
<heat>
what happened to the good old linux x86 boot protocol
<jafarlihi>
Do I need to create i686 cross-compiler if I boot with GRUB to 32 and switch to 64 myself? Or is just x86_64 cross compiler enough?
<heat>
will you boot in 16-bit mode? 32-bit? 64-bit? who knows??
<geist>
actualyl has me thinnking. grub-on-uefi on a 64bit machine. does that actually explicitly drop to 32bit before starting something?
<heat>
yes
<geist>
64bit cross compiler is enough
<heat>
multiboot1 and 2 specify 32-bit, so it needs to drop down
<geist>
a 64bit x86 compiler can happily generate 32bit or even 16 bit assembly at least, if not actually compile 32bit C code
<heat>
EXCEPT if you tell GRUB not to exit boot services (multiboot2)
<heat>
something I've realized is that 32-bit x86 code is hard
<heat>
at the very least it's super non-trivial to include in an x86_64 kernel
<heat>
you can't link elf32 with elf64
<heat>
and at least I haven't found a clearcut way to make it generate an elf64 with 32-bit code
<geist>
yah that's generally why i advise just a) sticking to 32bit asm if you need to link it and b) compile it as 64bit .S
<heat>
i would like to do things like KASLR
<geist>
actually linking an elf32 .o with an elf64.o requires extra hackery
<heat>
you can't just objcopy it because of the relocs I think
<geist>
i think it can be done with severe limitations
<geist>
right, basically you have to avoid most of the relocs, then you can try to objcopy it
<Griwes>
My only 32 bit code is inside an asm file that gets compiled as elf64
<geist>
usually in the past if i needed something more than a simple 32-to-64 boot32.S file, i would compile the 32 bit as a separate flat binary and define a protocol to branch between them
<geist>
ie, have the 32bit binary do whatever it needs and then directly jmp to a 64bit flat binary
<geist>
and just cat the two together in the payload
<heat>
i had a fully physically relocatable x86 kernel thanks to multiboot2 but it turns out their relocation is broken
<heat>
so i really really don't trust grub mb2
<heat>
it killed off the trust i still had
<geist>
yay x86 bootstrapping
<geist>
it can be fun if you like that sort of masochism, but in general its only fun in the way fiddling with esoteric old 1980s systems are fun, sometimes
k8yun has joined #osdev
<geist>
ie, fun to fiddle with, unfun if you want it to actually work reliably
<jafarlihi>
Is there an easier arch out there than x86 for beginners to create OS for but still not be simple enough to not support things like GUI?
<kazinsal>
x86 bootstrapping gives me sad
<heat>
riscv, arm64
<jafarlihi>
Is RiscV really all that easier?
<heat>
yes
<heat>
it's just a trashy architecture
<jafarlihi>
How does arm64 compare to RiscV on that?
<kazinsal>
every time I crack open my repo named "x64core" I look at it for all of two minutes then go "yeah I'm just gonna go rewatch the expanse or something actually fun"
<heat>
riscv is the trampstamp of kernels
<gog>
neat
<heat>
s/kernels/architectures/
<geist>
yes riscv is far more straightforward. the main downside being that it's hard to find physical hardware to run on
<geist>
so you'll have to be content for the most part with an emulator
<heat>
32-bit hw is relatively available
<geist>
OTOH when you're just getting started i highly recommend mostly sticking with emulators anyway
<heat>
64-bit, hard nope
<geist>
since you have way more tools available
<geist>
i guess the only annoying thing to learn with riscv64 is the whole SBI thing, but you only need that once you start trying to run in supervisor mode
<geist>
and even then it's not hard to implement, just a little bit of a conceptual jump
<heat>
"what if your syscalls had syscalls"
<geist>
yo dawg i heard you like timers
<heat>
yo dawg, i heard you didn't like timers, so u dont even have to touch one directly
<geist>
but once you accept that all that stuff is out if your control, its pretty nice. if you ignore that it's probably slow
<geist>
(i think there's some new spec stuff for a supervisor level timer hardware, so you can drive your own)
<heat>
woah
<geist>
presumably because the whole SBI timer stuff folks have decided is too slow/inefficient
<jafarlihi>
Has anyone managed to make arm64 OS and run it on an Android phone device?
* geist
whistles
<geist>
if you mean take some random phone and hack your system on it? that's a fools errand, it's too hard in general
<geist>
but not because of arm64, but because nothing is documented anywhere
<heat>
LMAO
<geist>
everything is closed hardware in that world
<geist>
it can be done but it's mostly reverse engineering things, etc. definitely not a beginners task
<heat>
x86: i heard you like timers so i gave you like 5 of them and only 1 or 2 are decent
<heat>
pit, lapic, hpet, apic, tsc
<heat>
s/apic/acpi/
<geist>
yah was looking at the x86 port: still uses PIT, running at 1khz! yay
<geist>
having the pentium 4 out on the table is why i've been fiddling with LK x86-32 lately. kinda fun to blat it onto a floppy and boot it
<geist>
gives you a different set of feels
<heat>
heh
<kazinsal>
the 2022 equivalent of digging the old XT out of the closet
<heat>
aren't all the p4s 64-bit?
<geist>
oh no. only the later ones
<geist>
early p4s were out in like late 2001. AMD x86-64 wasn't until like 2003
<geist>
but iirc all of the Xeon P4s are 64bit
<CompanionCube>
lol 'lacpi'
<geist>
actually that may have been the first xeon
<geist>
P4 was all of the intel line from like 2001-2005 or so until the Core stuff came out, iirc
<kazinsal>
I think I remember looking at P3 Xeons back in the day
<geist>
looks like.... prescott was where P4 got x86-64
<geist>
kazinsal: yah you're probably right
<geist>
willamette and northwood were the first 2 p4 microarches. northwood seems to be where hyperthreading came along
<geist>
and prescott added 'intel 64'
<geist>
oh interesting, from wikipedia
<geist>
"The Prescott microarchitecture was designed to support Intel 64, Intel's implementation of the AMD-developed x86-64 64-bit extensions to the x86 architecture, but the initial models shipped with their 64-bit capability disabled. Intel stated that it did not intend to release 64-bit CPUs in retail channels, instead releasing the 64-bit capable F-series to OEMs only.[32] However, they were later made available to the general public as
<geist>
the 5x1 series. A number of low-end Intel 64-enabled Prescotts, with 533 MHz FSB speed, were also released."
<clever>
geist: i was looking into aarch64 ASID with heat earlier, and ran into some confusion, the ASID is held in TTBRn_ELn, so updating the pagetable atomicaly updates the ASID as well, however
<clever>
> TCR_ELx.A1 determines which of these holds the current ASID.
<geist>
clever: yep! which makes sense right? you swap the aspace by writing a new value in it, so you want to load the ASID
<geist>
and yep. the A1 bit is whats annoying. why can't they just have two ASIDs active at the same time on both halves
<clever>
geist: both TTBR0 and TTBR1, are tagged using the same ASID, selected by the A1 bit
<clever>
which then makes me wonder, how you can do aarch64 TTBR1 trampoline
<geist>
i dont think so, i think it selects which of TTBR0 or TTBR1's ASID is in use
<geist>
and the one that isn't tagged is intrinsically running without ASID
<geist>
which i think is functionally equivalent to ASID=0
<clever>
but to make the userland TLB cache right, userland should always be active?
<clever>
so the kernel ASID can never vary?
<geist>
right
<clever>
and the trampoline needs its own ASID, or you have to TLB flush constantly
<clever>
now what?
<geist>
so the usual way of doing it is selecting that TTBR0's ASID is active, and assign one for user space thats > 0
Lumia has quit [Quit: ,-]
<geist>
what do you mean 'trampoline'?
<clever>
meltdown protections
<geist>
oh i dunno, it's complicated is the answer
<clever>
have a dummy kernel that just changes TTBR1
<geist>
and i frankly just dont want to think about it rght now
<heat>
clever, did you see the darwin solution?
<heat>
it's funny, they just change the address space size to only include the trampoline entry
<clever>
heat: only thing ive heard about darwin, is that the entire lower 4gig of the virtual space is banned
<geist>
yah that's probably another strategy
<clever>
ah, i can see that working
<geist>
you can use TCR_EL1 to set the aspace size. that makes good sense
<clever>
and then even if you have a TLB hit, its not in the valid size
<clever>
so it should fault?
<geist>
i forget the smallest you can set it to, but if it's say 30 bits you can just burn the top 1GB of the kernel as the trampoline
<clever>
but then again, meltdown is it leaking when it should have faulted!
<geist>
theres some new v8.x feature to build even smaller aspaces (basically extends those bits)
<clever>
do you trust the cpu to not have the exact same problem with the size flag?
<geist>
maybe that's what this is for. i was always wondering what that feature was for
<geist>
clever: yes. you do. also easy to do when you build your own cpus
<clever>
but if i was to implement a heartbleed resistant kernel, on a core i lack the source to
<clever>
my only option is to either trust or test
<heat>
heartbleed?
<heat>
wrong vuln?
<heat>
:D
<geist>
ir assume the worst and add all the mitigations you know about
<clever>
heat: too many exploits bouncing in my head, lol
<geist>
and KPTI is one of those. but i forget the precise details of how linux does it
<heat>
anyway, if i were to write a shellshock resistant kernel...
<heat>
:D
<geist>
but that's probably the canonical solution
<geist>
whatever darwin does may or may not be the 'best' solution, since they build their own hardware
<geist>
they can tune whatever their mitigations are for their own design
<clever>
yeah
<clever>
and they can answer every question i gave above, by just reading the implementation of the core
<clever>
and design a proper fix
<geist>
but the TCR 'turning off' the aspace seems like a solid design
<geist>
if they can be sure that the cpu will fault early based on an address being outside of the aspace
<heat>
yeah i assume that's a lot simpler and more reliable
<heat>
if bits[X...Y] != 0, fault
<clever>
i assume there is also a cpuid flag, to tell you if meltdown has been fixed in hw?
<clever>
and then you can disable your KPTI, to regain the performance
<heat>
x86 doesn't AFAIK
<heat>
you just cpu_bug based on the family/model
<clever>
ah, and hard-code the list of cores that are fixed?
<geist>
i think there are *some* in some cases though
<heat>
you assume everything past gen X has been fixed
<geist>
i just can't tell you the which ones off the top of my head
<bslsk05>
lkml.org: LKML: Tom Lendacky: [PATCH] x86/cpu, x86/pti: Do not enable PTI on AMD processors
<heat>
the great march
<geist>
i think in general there are some more interesting modern vulns being found on zen 1 and 2, but from what i understand 3 and 4 are very solid cores (currently)
<heat>
CompanionCube, LMAO
<heat>
i think it was publicized in what, january?
<CompanionCube>
iirc it was just after new years?
<jafarlihi>
2/exit
jafarlihi has quit [Quit: WeeChat 3.7]
awita has joined #osdev
awita has quit [Remote host closed the connection]
netbsduser has quit [Remote host closed the connection]
<bslsk05>
twitter: <sortiecat> I just finished my new init system for my Sortix operating system. A thread on how it's super simple and powerful with fast parallel startup in dependency order, portable daemon readiness signaling, reliable logging, and is easy to configure per init(5): <pub.sortix.org/sortix/release… https://t.co/ydIqY0LgUl>
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #osdev
wootehfoot has quit [Read error: Connection reset by peer]
<heat>
"ok boss, you said -fno-omit-frame-pointer, we won't omit the frame pointer"
<zid>
yea gcc likes to mess with stack frames even if you ask it nicely not to a lot
<zid>
I've had it adjusting rsp in leaf functions quite aggressively too
<heat>
my issue here is gcc taking me too literally :D
<heat>
most of these thunk functions should either be "jmp dst_syscall" or "call dst_syscall; cltq; ret"
<zid>
gcc seems to have some weird hardcoded logic for what constitutes a frame pointer etc
<zid>
and it gets confused a lot
<heat>
they're too small for a frame pointer, and setting up + tearing down a framepointer for a tail call is the stupid
<kazinsal>
thunkmmmmmmm
<heat>
it's either thinking or very hungry
<epony>
after it's not that hungry it won't be thinking that much either ;-)
<epony>
"stay hungry" --steve jobs, the reseller of failed computers
<epony>
(expensively)
nvmd has quit [Quit: WeeChat 3.7]
axis9 has joined #osdev
axis9 has quit [Ping timeout: 272 seconds]
axis9_ has joined #osdev
<geist>
yeah in that case it decided it was an interesting function thus needs a frame pointer, but then decided to tail chain it, which by definitoin has to happen after the frame pointer was cleaned up
axis9_ is now known as axis9
vdamewood has joined #osdev
<geist>
i wonder would it still set up a frame pointer even if the function did literally nothing but return?
<geist>
if so, i guess it's at least still being consistent
<geist>
though interesting gcc 12.2 doesn't do a frame pointer for arm64, x86-64 or -32
<geist>
so seems to be some riscv codegen nonsense
<geist>
it does for arm32 though. so it seems to be highly arch specific. i dunno if that's actual ABI requirements or just different implementations of the back end