gxt has quit [Write error: Connection reset by peer]
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
gxt has joined #osdev
bauen1 has quit [Ping timeout: 240 seconds]
wand has quit [Remote host closed the connection]
pretty_dumm_guy has joined #osdev
wand has joined #osdev
pie__ has quit []
vancz_ has quit []
pie_ has joined #osdev
vancz has joined #osdev
bauen1 has joined #osdev
freakzoid333 has quit [Ping timeout: 240 seconds]
the_lanetly_052_ has joined #osdev
the_lanetly_052 has quit [Ping timeout: 264 seconds]
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
gog has joined #osdev
toluene has quit [Quit: Ping timeout (120 seconds)]
toluene has joined #osdev
vin has quit [Quit: WeeChat 2.8]
wand has quit [Remote host closed the connection]
gxt has quit [Remote host closed the connection]
wand has joined #osdev
gxt has joined #osdev
wand has quit [Read error: Connection reset by peer]
wand has joined #osdev
nyah has joined #osdev
gildasio has joined #osdev
elastic_dog has joined #osdev
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale has joined #osdev
X-Scale has quit [Ping timeout: 255 seconds]
bliminse has quit [Ping timeout: 240 seconds]
heat has joined #osdev
bliminse has joined #osdev
X-Scale has joined #osdev
SGautam has joined #osdev
xhe has quit [Read error: Connection reset by peer]
xhe has joined #osdev
nur has joined #osdev
gog has quit [Ping timeout: 268 seconds]
gog has joined #osdev
noeontheend has joined #osdev
<mxshift>
If by scrambling, they mean knew about it over 6 months ago, then yes
[itchyjunk] has joined #osdev
dude12312414 has joined #osdev
noeontheend has quit [Ping timeout: 240 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
matt__ has joined #osdev
matt__ is now known as freakazoid333
xhe has quit [Ping timeout: 244 seconds]
xhe has joined #osdev
freakazoid333 has quit [Ping timeout: 244 seconds]
noeontheend has joined #osdev
mzxtuelkl has joined #osdev
<gorgonical>
I'm pretty sure I found a mistake or bug in Linux RISCV. Basically the memblock/bootmem allocator I don't think can use any memory from start of DRAM to where the kernel was physically loaded due to the behavior of the __va() macro
<gorgonical>
I don't know about that yet. I only know it'll fall below the page_offset if you try. I have to check and see where the bootmem bounds are
<mrvn>
GeDaMo: It's not a division, it's the remainder.-
<mrvn>
What's the point of `ror edi,6; cmp edi, 4294`? Couldn't you do `cmp edi, (4294 rol 6)`?
HaxCPU is now known as Andrew
<gorgonical>
Okay so I think it's possible, but maybe doesn't happen because the memblock allocator goes top-down
Andrew is now known as HaxCPU
frkazoid333 has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 276 seconds]
xhe has quit [Read error: Connection reset by peer]
xhe has joined #osdev
<heat>
gorgonical, not a bug
<heat>
older arm64 kernels also had that issue
<gorgonical>
Interesting
<zid`>
so if you load the kernel too high you lose the memory underneath, or what?
<heat>
yes
<gorgonical>
Do you know off the top of your head any mailing list discussions that reference it?
<heat>
no
<gorgonical>
Yeah since it's only ~2MB for opensbi it's not that big of a deal, it surprised me is all
<zid`>
That's perfect for x86
<heat>
but that detail is mentioned in arm64's boot protocol "spec"
terminalpusher has joined #osdev
<zid`>
cus you load it at 640k and go "fuck everything under this" :p
<zid`>
/1MB
<gorgonical>
zid`: It's not exactly that you lose it, but the regular macros will lose it
<zid`>
good good
<heat>
you do lose it because the page allocator gets the memory regions from memblock
<gorgonical>
Because the __va() macro basically can't generate a valid vaddr between the start of DRAM and the load addr of the kernel
<mrvn>
gorgonical: There is stuff below 1MB you dare not touch. Figuring out all the pages you may and may not use is complex and really, it's 1MB, who cares?
<gorgonical>
heat: at least in the riscv code it looks like the memblock still thinks the bottom of memblock is start of DRAM, but I am not sure yet
<zid`>
good good
<mrvn>
gorgonical: (x86 side). riscv and most other archs probably just inherited that glitch.
<gorgonical>
but anyway if you allocate from the back downward you will almost surely never have a problem
noeontheend has quit [Ping timeout: 260 seconds]
<gorgonical>
one day I'll show up with a bug or snippet that's new
<zid`>
You should show up with pizza
<gog>
I'm getting shawarma
<zid`>
I had an wrap the other day it was preeeetty good
<zid`>
was too hot to cook
<mats1>
ask mommy to do it
<gorgonical>
gog: is it from that one that's the only one open late
<gog>
nah alibaba
<gorgonical>
no hakarl and hardfish for gog today huh
<gog>
nah I prefer food that's edible
<zid`>
I googled for a doner wrap and all the pictures are too clean
<gorgonical>
god almighty I love kebab. Why you do this to me
<gorgonical>
I'm on a diet
<zid`>
so don't eat six of them
<zid`>
cut in half, rest in fridge, 2 dinners <3
<gorgonical>
This hellish desert I'm in is very low on kebabs
terminalpusher has quit [Remote host closed the connection]
<mrvn>
gcc is having fun with a simple recursive function: https://godbolt.org/z/M9bfM68P8 What is "gcc -O2" thinking there? On the other hand check `destruct5` in "gcc -Os" output.
<bslsk05>
godbolt.org: Compiler Explorer
<zid`>
which is weird, because the hellish desert known as turkey has loads
<heat>
turkey doesn't exist anymore
<heat>
it's turkiye
<zid`>
actually doesn't it have an umlaut on the i
<zid`>
to which my response was, nope, fuck off, you're turkey :P
<gog>
zid`: no that looks good tho
<zid`>
smh no bananas :(
<zid`>
I get lamb doner wrap, light salad, chili sauce
<gog>
i got lamb with garlic sauce and onion and tomato i didn't see any peppers like that there
<zid`>
I just ask
<gog>
I'll ask next time
j0hn has joined #osdev
<mrvn>
they never have lamb here. They do have chicken / turkey sometimes.
coso has joined #osdev
frkazoid333 has quit [Ping timeout: 272 seconds]
frkzoid has joined #osdev
nur has quit [Ping timeout: 272 seconds]
frkzoid has quit [Ping timeout: 272 seconds]
matt__ has joined #osdev
matt__ is now known as freakazoid333
vdamewood has joined #osdev
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
noeontheend has joined #osdev
dude12312414 has joined #osdev
freakazoid333 has quit [Read error: Connection reset by peer]
freakazoid333 has joined #osdev
eck has quit [Quit: PIRCH98:WIN 95/98/WIN NT:1.0 (build 1.0.1.1190)]
eck has joined #osdev
noeontheend has quit [Ping timeout: 260 seconds]
jafarlihi has joined #osdev
bauen1 has quit [Ping timeout: 272 seconds]
freakazoid333 has quit [Ping timeout: 272 seconds]
dude12312414 has quit [Remote host closed the connection]
foudfou has quit [Remote host closed the connection]
dude12312414 has joined #osdev
foudfou has joined #osdev
frkzoid has joined #osdev
gorgonical has quit [Quit: Leaving.]
gorgonical has joined #osdev
frkazoid333 has joined #osdev
frkzoid has quit [Ping timeout: 244 seconds]
gorgonical has quit [Quit: Leaving.]
frkazoid333 has quit [Ping timeout: 244 seconds]
gorgonical has joined #osdev
bauen1 has joined #osdev
mzxtuelkl has quit [Quit: Leaving]
bauen1 has quit [Ping timeout: 240 seconds]
<geist>
gorgonical: side note the #riscv channel has some of the folks that work on linux, they might be able to help as well
bauen1 has joined #osdev
<geist>
my impression is a lot of the earlier linux kernel riscv dev was mostly sifive bringing things up on their boards
<gorgonical>
Yeah often I am in that channel, too. Much less traffic than here so I'll often ask here first. I'll try to be less Linuxy in the future questions
<gorgonical>
I realize recently I am asking a lot of linux questions in the weak guise of my own lwk
<geist>
oh no worries. mostly. just in that you might get more direct answers there
<geist>
oh asking linux questions for the purposes of leaning an arch or whatnot i dont mind much. ore really just linux questinons in moderation are fine. just dont want to turn the channel into a linux helpdesk
<geist>
ie, 'there are smart people ther,e lemme ask about my distro' etc
<gorgonical>
I see. i've tried to keep the linuxdev questions down but the linux channel is almost entirely general user talk and I don't think I've ever gotten a direct answer to a kernel question there
<geist>
yeah, tis the curse of real linux devs not using chat i guess
<mjg_>
there is a slight chance that #kernel will be fine
<mjg_>
although i have not visisted it in 7 years or so
<mjg_>
for all i know it's a total shitshow now :-P
<geist>
that or you get stabbed in the face as soon as you go in
<gorgonical>
I think I have been in kernel once or twice. I think the last time I asked something I got accused of doing something the wrong way
<geist>
or it didn't migrate to libera
<mjg_>
also it was on freenode, i don't know where they landed
<gorgonical>
Which is exactly my research, to do kernel stuff weird
<geist>
well, with all these spectre things weird is the only way now
<gorgonical>
indeed
<clever>
mjg_: speaking of freenode, i connected to irc.libera.net last week, and discovered its CNAME'd to freenode!
<geist>
spent a bunch of time talking about the retbleed thing and basically, shit it's bad
<clever>
irc.libera.net. 120 IN CNAME chat.freenode.net.
<geist>
honestly all of this stuff really takes most of the fun out of kernel dev
<mjg_>
clever: ye, had the same problem once :-P
<clever>
thats just nasty :P
<geist>
since at the end of the day you end up having to just build a shitty codebase with so much slowdown in it there's no fun optimizing or designing anything
<clever>
they are that depserate to reclaim users
<gorgonical>
clever: you're right!
<mjg_>
geist: i don't know about htat, it definitly hinders optimizing for single threaded
<gorgonical>
I just dig'd it. wtf yo
<mjg_>
geist: you can still have fun solving problems and doing multicore
<clever>
gorgonical: exactly
<geist>
yeah i guess. it really takes the edge off the fun though
<mjg_>
geist: i mean big picture
<gorgonical>
I have friends arguing that VLIW cpus should come back
<mjg_>
geist: ye, i'm super bummed out myself
<geist>
since it's just minefield after minefield
<geist>
i'm having trouble staying excited about it
<mjg_>
i can't even sensibly compare older releases to new code looking for perf regressions
<clever>
gorgonical: the only VLIW ive used recently, is the QPU on the rpi, where shaders run, each 64bit opcode encodes 3 seperate actions, that all run in parallel
<geist>
was thinking. on one hand µkernels may be better off in an extreme environment like that since you can just have less kernel running
<geist>
OTOH the expense of syscalls and shuffling data around goes up
<geist>
but stuff like drivers, file systems, networking are outside of the kernel and thus dont need to be extreme nerfed
<mjg_>
i don't believe microkernels. all the talks supporting them that i found were beyond bogus
<geist>
oh that's why you gotta look past the talks and just do it
<geist>
like all real things it's shades of grey
<immibis>
just optimize it with spectre vulnerability turned on, surely
<mjg_>
i was particularly pissed at "researches" who claimed their microkernel http daemon is a great example of win
<mjg_>
.. compared to APACHE
<geist>
immibis: yeah but every week there's a new one, and a lot of them are *bad*
<mjg_>
one thing they compared is startup time, which i know for a fact is gimped by default -- apache injects a sleep(!)
<geist>
like, the canonical soluition to this one is to literally route all ret instructions into a single one
<mjg_>
it can be turned off
<geist>
and then have that dump the entire return branch
<mjg_>
i'[m guessing immibis was sarcastic
<immibis>
if you turn on being vulnerable to data leaks, you can have all the fun you want
<clever>
potentially related, i recently stumbled upon a darwin util, that returns exit code 253 upon success
<immibis>
don't ask me though, i haven't touched osdev since i was like 13
<geist>
theres an ARM one i have to look into soon that *nails* syscall performance
<immibis>
clever: is the QPU aligned?
<immibis>
(bad pun)
<\Test_User>
immibis: more like just disable spectre on the cpu then optimize all you want :P
<geist>
basically for every entry into the kernel you have to make an EL3 call, which then makes a trusted EL1 call and bounces back
<geist>
so it takes say a 400ns syscall minimum to 1200
<clever>
immibis: pretty sure it is, things malfunctioned when my shader wasnt
<mjg_>
geist: i don't know if you know or even can talk about it, but does G run with all these mitigations in production?
<geist>
not sure and i couldn't say if i did, but there are folks within G that are *incredibly* on top of this stuff
<geist>
which is where i generally hear about it
<geist>
it is interesting a bunch of these mitigatinos actually kinda drives oneself to consider running an AMP kernel:
<geist>
ie, kernel runs on cpu 0 while user stuff runs on 1+ (or some other semi static partition)
<mjg_>
hrm
<immibis>
and do syscalls via shared memory?
<geist>
via some sort of mailbox thing probalby yeah
<gorgonical>
geist: this is sort of the approach we take with co-kernels
<gorgonical>
but not for security reasons
<immibis>
it's not just the kernel - you'd want every security partition to run on its own processor as much as possible
<immibis>
every process, in most cases, or processes from the same user without sandboxing
<\Test_User>
"1 process per core, have fun running a full system"
<geist>
if each of the user cpus is running essentially just a little mailbox kernel you can really lock it down and then the main one can run on dedicated cpus that dont share any hyperthreads without a lot of the egregious mitigations, etc
<geist>
no you can run more than one process per core, but the point is the heavy lifting of the kernel never runs on the same cores as user code
<geist>
and thus the amount of ring0 code you have to really lock down goes down
<immibis>
no, it's not just the kernel that needs to be segregated from user processes, but also user processes from each other
<\Test_User>
^
<gorgonical>
another interesting angle is ideas like m3, where expressly you don't multiprocess
<clever>
\Test_User: that reminds me, i saw a story before, about an idiot that assumed you need X mb of ram, for every visitor on your website
<immibis>
the kernel/user transition is a context switch, one that previously could be optimized
<geist>
oh sure, but that's baiscally a given. you can still context switch between the you just have to dump all the state
<\Test_User>
lol
<immibis>
context switches get more expensive. kernel calls actually get a lot CHEAPER if you do them asynchronously with a ring buffer
<clever>
\Test_User: so she pre-paid a MASSIVE server, for a full year, and then demanded to know where the wordpress login was, it was fully unmanaged
<\Test_User>
XD
<clever>
\Test_User: and when support couldnt solve her issue, she turned to her credit card company to yell fraud
<clever>
the bill was over $10k
<immibis>
some places have cooling-off-period laws for this sort of thing - you have 7 days to ask for a cancellation and full refund, no questions asked
<immibis>
oh, btw if all your communication between processes is through mailboxes/ringbuffers and you have big security partitions with many processes in the same partition... you may as well try a microkernel
<clever>
i think steam rules, are that you can get a refund if you purchased a game less then X days ago, AND you have played it less then Y hours
<jafarlihi>
Linux defines its IDT table to be 256 long, what happens when a process does `INT 257`?
<clever>
jafarlihi: does the assembler even allow that?
<\Test_User>
is int 257 even possible to encode
<\Test_User>
or 256 for that matter
<jafarlihi>
Why not? Max IDT entries can be 4096
<\Test_User>
(0-255 would be valid)
<\Test_User>
eh? then probably just a fault
<jafarlihi>
But it calls the "handler" that happens to be at IDT_TABLE[257]?
<\Test_User>
the cpu knows the idt length
<jafarlihi>
How?
<dh`>
it's a segment
<immibis>
jafarlihi: it's part of the IDTP
<\Test_User>
lidt takes a descriptor with both a pointer and a length
<jafarlihi>
Oh right, thanks
<jafarlihi>
Oh right, thanks
<jafarlihi>
oops
<clever>
\Test_User: does it copy the entire structure into the cpu, or just store the pointer+length in a reg, and look it up later?
<geist>
plus x86 only defines up to 256 anyway. the max you can set in the length is the equivalent of that
<\Test_User>
clever: not sure
<\Test_User>
haven't poked it that much yet
<geist>
(i do wonder why neither intel or amd has extended that over the years past 256)
<GeDaMo>
exit
<geist>
FRED however makes it moot i think
<geist>
unless they only allocate a uint8_t in the exception frame message
<gog>
the while idtr is stored in a register pair
<gog>
at least i think it is because when loading descriptor table registers i put them on the stack
<gog>
and it works fine
<geist>
idtr (and gdtr and ldtr i think) use a 16/32 or 16/64 packed structure
<geist>
16 bit length + pointer
<gog>
yes
<geist>
anyway, they could have extended the number of interrupts out to (16-3)^2 irqs a long time ago, but never did
<gog>
well no i think the ldtr takes a selector index and the gdt has the ldt data? maybe I'm remembering wrong
<mjg_>
> Tentative numbers put IBPB-on-entry at a 2.5x hit on Zen2, and a 10x hit
<mjg_>
on Zen1 according to lmbench.
<mjg_>
ffs
<mjg_>
sorry to interrupt :)
<gog>
ayyyy
<jjuran>
RTE
frkzoid has joined #osdev
radens has joined #osdev
<mrvn>
jafarlihi: if you do "int 1234" you get a different exception because 1234 > size of the IDT.
<immibis>
one day we'll see netspectre, where some part of the kernel's packet handling code contains a spectre condition without the need for a context switch
<immibis>
and by recording minute variations in ping times we can determine the state of the cache
<radens>
Okay, silly question -- I have my armv8 physical timer set up and my gicv2 set up and I checked by stepping through qemu that they seem to be configured correctly, but the timer is not generating a trap to the vbar irq entry. If I wfi & rearm the timer in a loop I see the loop execute every second. Is there something I need to set somewhere to make the timer do a trap when the interrupt fires?
<radens>
immibis: hm I think they made something like that happen in a lab already and wrote a paper about it. netspectre iirc
<bslsk05>
arxiv.org: [1807.10535] NetSpectre: Read Arbitrary Memory over Network
<geist>
mjg_: yeah from what i understand zen1, 1+, and 2 are affected. apparently zen 3 isn't, though not because AMD explicit went out to fix it
<geist>
they just had redesigned the front end for zen 3 enough and got lucky
<geist>
radens: double check that you have the right IRQ #? the 4 timer vectors are in the PPI irq space (16-31) but not always consistently allocated
<jafarlihi>
When I do `cat /proc/interrupts` many of the 256 are missing. When I fetch the table myself using LKM, all 256 are populated with present bit set. How come?
<gog>
the kernel has stub handlers
<geist>
jafarlihi: probably just routes all of them to a single set of software vectors to catch all of them
<geist>
yah stubs
<geist>
radens: if that still doesn't work, what sort of environment are yo urunning on? ie, are you on physical hardware?
<jafarlihi>
The handler addresses are not same but contigious
<jafarlihi>
Yes
<geist>
if so, are you in EL2 or EL1? and is there an EL2 there?
<CompanionCube>
i imagine the handlers probably complain in dmesg about weird interrupts
<immibis>
jafarlihi: IIRC there's no way to get the interrupt number on x86 other than having a separate interrupt for each one
<immibis>
a separate handler*
<geist>
jafarlihi: yeah each handler probably pushes a irq # on the stack and branches to another one
<geist>
that's a common pattern in x86
<radens>
geist: I am in el2. I just enabled irqs 16-31 for good measure
<geist>
radens: ah okay. so physical *really* should be available
<geist>
otherwise was gonna say physical might be masked off for you
<geist>
can you try one of the other ones? virtual timer etc?
<radens>
Well unless I was dumb and masked it off for myself, which could be
<geist>
unless you have an exotic EL3 that's doing weird shenanigans, EL2 should porobalby have full access to the physical timer
<jafarlihi>
What is EL?
<gog>
ARM stuff
<geist>
jafarlihi: in arm64 there are 4 priviledge levels (EL3 is highest, EL0 is lowest).
<gorgonical>
el = ring
<gorgonical>
but backwards
<geist>
right, such that EL0 == user space, EL1 == kernel, etc
<gog>
hringur
<gorgonical>
sounds like your uncle wheezing as he asks for a ring
<mrvn>
gorgonical: EL == what ring should have been
<gog>
if you like it then you should have put a EL on it
<radens>
geist: hm I see the same behavior with cntv_.*_el0
<geist>
well, that's good then. it's something probably more straightforward. can you look on the gic and read the raw PPI input registers?
<geist>
i think that exists. usually i start there to see if the timer block is at least asserting the irq
<geist>
that way you can bifurcate the problem into interrupt generation vs interrupt reception problems
bliminse has quit [Quit: leaving]
<immibis>
"should have been" except for the part where EL3 is often written by your device vendor to avoid you having control of your own device.
<geist>
indeed. however most of the time it's just arm's trusted firmware code, which is pretty dumb
<geist>
it's vendors like qualcomm or whatnot that insists on doing their own shit where you really lose the keys
<bslsk05>
www.toptal.com: Hastebin: Send and Save Text or Code Snippets for Free | Toptal®
<geist>
ah if you're on qemu i'd start by just running with `-d int`
<immibis>
recently in the news: BMW wants you to pay $19/month for heated seats
<geist>
then you can see if the timer is generating the interrupts
<geist>
then you get the bifurcation of problem space for free
<immibis>
restricting people from using their own devices is basically the same business model
<radens>
-d int -D qemu.log gives me an empty qemu.log.
<radens>
daif are 0 btw
<gorgonical>
anyone got an authoritative scheme for saying long hex numbers, like 0x8020'000?
<gorgonical>
it has always bugged me
<geist>
hmm! that would tend to tell me your timer isn't firing
<geist>
gorgonical: usually i put a _ or ' in it every 4 chars
<geist>
in C++. you can do the ' though lots of editors complain
<gorgonical>
Oh I mistyped that, should be 0x8020'0000
<geist>
but we do that in zircon quite a bit and it's nice
<gorgonical>
But if you were trying to verbally say it what would you say, geist
<geist>
oh oh. i tend to personally say something like 'eight oh two gazillion'
<radens>
CNTV_CTL_EL0 shows 0x5 which iirc means istatus is 1, imask is 0, and enabled is 1
<geist>
and then implicitly or explicitly define that am talking about 32 or 64 bit values
<geist>
there 'gazillion' i use for 'enough zeros to fill out the rest of the space i was talking about'
<geist>
if it's substantially long. if it's somehting like 0x1000 i'd say 'hex one thousand'
<gorgonical>
that's basically the scheme I use, which is unfortunate. I was hoping ye greybeards knew a clever scheme
<geist>
alas no
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<geist>
but i *do* find that prefixing with 0s up to the space i'm dealing with is really important. or if saying or typing something out i always do it in units of 4
<geist>
ie, oh oh oh one <space> oh oh oh oh
<gorgonical>
is that for ease of saying or because there's some internal logic for you?
<geist>
just leaves the amount of mistypings down to a minimum, since your brain can't read much more than 3 or 4 0s in a row without smearing it out
<geist>
internal logic, ie, always makes sure you dont forget or add another digit on accident
<gorgonical>
Like 1,000,000 is a million and so clumping the digits in threes makes it easier to read. does 0x8020'0000 have more "comprehensibility"
<gog>
PEnnsylvania hex one thousand
frkzoid has quit [Ping timeout: 268 seconds]
<geist>
number of times i've typed say 0x1000000 when i meant 0x10000000 for example
<geist>
if i always type the first one as 0x01000000 in units of 4 it's pretty hard to mess up
<geist>
yes when dealing with hex i use units of 4 because powers of two
<geist>
that way you always end up filling out a full cluster of 4 (except a byte of course)
<geist>
but 8 chars in a row is too error prone to eyeball
<geist>
and 2 is too much granularity
<gorgonical>
Oooh
<gorgonical>
I understand now the leading zeroes
<geist>
yah i can't easily show it but when i type those constants in i always do it as cluster of 4, then a small space, then another 4
<geist>
doesn't matter as much for 32bit values, but when yuo get into 64bit values you pretty much gotta do that or you'll mess it up
<geist>
or use ' if you're in C++
<geist>
or use powers of two where appropriate (1UL << 48) sort of stuff
<gorgonical>
I haven't fully acquired the instant hex math I need. I still have to think about how 0x22 is 16*0x12. I basically only know the common page sizes by sight
<gorgonical>
err it isn't even
<mrvn>
Using 0x100'0000 helps
<gorgonical>
see
<gorgonical>
Anything that's not 0x1000, 0x200000 or whatever I have to break out the hexcalc
<gorgonical>
:(
<gog>
16 x 0x12 is 0x120 :p
<geist>
yah the other key observation that's nice to know is every 10 powers of 2 is another SI unit
<geist>
thats how you can easily spot things like 64GB == 2^(30 + 6)
<geist>
because 2^6 == 64 (just memorize the ones below 10) and then you can construct the higher ones easily
<gog>
and then you can use your fingers to count to 1023
<mrvn>
after that also use toes
<geist>
and yeah memorizing the common ones like 4096 == 2^12 and 65536 == 2^16
matt__ has joined #osdev
<geist>
you can interpolate the other ones pretty easily
<gorgonical>
it always trips me up that the powers of 10 switches between 0x1... and 0x4...
matt__ is now known as freakazoid333
<gorgonical>
It is nice to recognize that there's always 3 more zeroes, though
<geist>
gorgonical: i think only up to a point, i think it eventually picks up enough error that it 'rolls over'
<gorgonical>
argh that isn't even true. 2^20 and 2^30 only have two zeroes
<geist>
when i really started dealing with 64bit kernel and address stuff about 10 years ago seriously, i found that thinking in powers of 2 really helps a lot
<gorgonical>
I do like that exponential thinking though
<geist>
with 32bit you can eyeball/memorize it a bunch, but with 64bit or greater its too hard
<gorgonical>
yeah that's probably a really good idea
<geist>
also lets you fairly easikly scale things like if you have a 48 bit address space and you have a 1TiB mapping. you can fit 256 of those in the space
xenos1984 has quit [Read error: Connection reset by peer]
<geist>
since 48 - 40 == 8
<mrvn>
gorgonical: 10^1 = 0xa. How is that "0x1... and 0x4..."?
<gorgonical>
the orders of bytes
<gorgonical>
1kb = 0x400, 1mb = 0x100000
<gog>
remembering 2 shorts in hex is fairly easy but 4 is like just beyond the reach of working memory for the human brain i think
<gorgonical>
1gb = 0x40000000, etc
<mrvn>
gorgonical: that's powers of 2 that are multiples of 10.
<bslsk05>
arxiv.org: A Proposal for Proquints: Identifiers that are Readable, Spellable, and Pronounceable
<geist>
(and i dont usually do the KiB vs KB stuff that much but i was being mroe precise here becuase i just *knew* i would get nerd sniped if i didn't)
<dh`>
this is why I have no plans to make os161 64-bit
<gog>
nerrrrrd
bliminse has joined #osdev
<gog>
axksually
<dh`>
students have enough things to worry about without dealing with 64-bit addresses
<mrvn>
dh`: just teach then to handle N-bit addresses and then 64-bit is easy.
* dh`
sighs
<geist>
probably hard to imagine how hard it is for some students to grok some of that stuff
<geist>
until yo have to deal with it
<geist>
keeping folks focused on the stuff that matters is probably far more important
<gorgonical>
mrvn: I don't understand what you mean
chartreuse has joined #osdev
<mrvn>
Just like in math you teach N-dimensional vectors and NxM-dimensional matrixes and then 3x3 and 4x4 in computer graphics is trivial.
<gorgonical>
about the powers of ten thing. it's the same
<gorgonical>
sorry
<jafarlihi>
exit
* geist
rolls eyes at mrvn
jafarlihi has quit [Quit: WeeChat 3.5]
<geist>
that sounds like a mathematician speaking
<geist>
'i mean it's so easy to understand'
<geist>
that N-dimentional vector and matrix stuff exactly kicked my ass in college. the one math class i had to take twice
<geist>
like all tricky topics teaching someone is about turning on that little a-ha bit in their head. sometimes it just pops on, sometimes it's stubborn
<mrvn>
geist: It comes in handy when you write your template <typename T, std::size_t N> Vector { }; class
<geist>
but if you have the bit set in your head it's hard to imagine now having it set
<geist>
s/now/not
<mrvn>
I think it's more. Some people can just think in variables instead of numbers.
<geist>
i always find it an interesting mental challenge to walk backwards and try to teach someone something that you intrinsically 'get' nowadays. it's kinda fun to walk back through the process
<geist>
though really i'm not a teacher professionally, dh` is the actual pro here :)
<geist>
but i think in another life i'd probably have been a pretty good teacher
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
<mrvn>
And why when you change a recursive function with T*& into a itertive one you suddenly need T**
<gog>
i did tutoring for intro programming
<gog>
and i couldn't figure out how to teaxh
<gog>
I'm smart at teaching myself things
<gog>
but stupid and helpless like a baby at teaching othets
<mrvn>
They should have allowed "int & const p;" and "int &p = x; &p = y;"
<radens>
geist: cntp and cntv are routed to el1 because of bits I set in hcr :P
freakazoid333 has quit [Ping timeout: 264 seconds]
<geist>
radens: ah hah!
<geist>
so now it works?
xenos1984 has joined #osdev
<radens>
geist: ah well I think I want to use CNTHV_CTL_EL2, but guess what, my rust toolchain doesn't know about those registers
<immibis>
thinking in powers of 2 is how IPv6 only ended up adding 13 real bits to the public internet
<mrvn>
gog: first job of teaching: buy a rubber ducky.
<immibis>
"everyone who wants should get a /48"
<immibis>
(and the first 3 are used to indicate the addressing scheme)
<mrvn>
immibis: but then those /48 should be your MAC
<immibis>
or rather... "There are so many bits we can waste 48 of them to store a MAC address, no even better, 64 to store an expanded MAC addresss. Now let's use another 16 bits to indicate the network"
<immibis>
other way around, /48 indicates the first 48 bits are fixed, whereas the last bits have the MAC
<immibis>
at least they leave open the possibility of unreserving bits, because nothing in the protocol actually forces each network to be a /64, just convention
<mrvn>
immibis: how much hardware breaks if I declare a /120?
<immibis>
at worst you will be unable to route to your network on many ASIC routers that save hardware by only looking at the first 64. But you can aggregate together with other networks until you form a /64, use equipment within your network that doesn't have that limitation, and that should be okay
<mrvn>
A /64 is rather small too. that's just 65536 hosts with MACs.
<immibis>
mrvn: the MAC space overlaps itself...
<immibis>
oh I almost forgot "let's make the address based on your MAC address to prevent collisions" followed by "oh wait that's a privacy leak, let's use random addresses and just check for collisions, and we could do that in a 32-bit space too, but you still need a 64-bit space because of the MAC thing because we said so"
<mrvn>
immibis: I bet there is hardware that ignores the last 48bits because that's the MAC
<Griwes>
the reason it's /48 is that even with just /48, the global routing tables have a potential to grow ridiculously large
<immibis>
mrvn: I just said, many ASIC routers only look at the first 64 so don't support finer-grained addresses than that. But it's not baked into the protocol
<immibis>
finer-grained routes*
<mrvn>
immibis: you need mroe for the port
<Griwes>
2.8e+14 potential networks
<mrvn>
immibis: think local switch
<immibis>
the port is not part of the address. Actually it would be pretty cool if it was though. You could eliminate port numbers and that would *actually* be a reasonable use of address bits.
<gog>
quack
<mrvn>
immibis: port of the switch where you plug in the cable
<immibis>
allowing for a dynamic port/address bit allocation, no ability for ISPs to stop you having multiple devices, and no need for SRV records either
<immibis>
mrvn: ?
<immibis>
subnetting isn't based on physical port numbers. they can be arbitrary
<mrvn>
immibis: for the switch to know which port to send packets too it has to look at more than 64bit.
<mrvn>
80bit will do though generally
<immibis>
There are two layers involved. The IP layer determines the network to send the packet to based on the first 64 bits. The Ethernet layer determines the physical port based on the destination MAC address for that frame, which is the next hop router's MAC address, not the final destination's MAC address
<Griwes>
any device that looks at less than the bitmask of the subnet when routing is a piece of garbage that belongs in a recycling pile
<mrvn>
Griwes: ack
<immibis>
that MAC address comes from the routing table's next hop IP address -> this router's ND cache
<immibis>
Griwes: a lot of ipv6 routers require the subnet mask to be 64 bits or shorter
<Griwes>
and they belong in a recycling pile
<immibis>
this way they get twice as many subnets into the same hardware CAM table
<immibis>
instead of leaving half of it unused for a feature extremely few people are using
<gorgonical>
I'm getting a page fault when it literally isn't a page fault
<mrvn>
immibis: and /64 is a single host to them?
<gorgonical>
wtf
<immibis>
mrvn: huh? the host part is irrelevant to routing
<immibis>
except for the final hop
<Griwes>
anyway just do your routing in software
<immibis>
which may be a different processing path
<mrvn>
immibis: every hop can be the final hop
<Griwes>
this way you aren't bound by idiots at cisco when it comes to what you are allowed to do
<immibis>
No hop that matches a route in the routing table is a final hop. If it's the final hop it matches the subnet mask of a interface.
<mrvn>
immibis: and you can have host routes too, not just network routes
<immibis>
I mean you could connect something that emulates a router and some hosts, and then the non-final hop would be the final hop even though the router thinks it's not final, but you know, that's just emulation
<immibis>
mrvn: oh they probably wouldn't be supported
<mrvn>
immibis: or you have 2 tables, 64bit for ntworks and 128bit for hosts
<immibis>
that is also a possibility. The network table would be larger.
<mrvn>
a host route is basically just an ARP entry that's fixed.
<mrvn>
immibis: anything that allows final hops needs a host table or it would become a HUB
<mrvn>
That reminds me that I should fiish writing my "fakevpn" so that I can run a local chromium as if it where located at work (tunnel traffic via ssh)
<radens>
geist: setting bit HCR_IMO did it. qemu virt with cpu cortex-a57 faults when accessing cnthv_ctl_el2, but cortex-a76 does not, but I don't know the irq number for that machine
<immibis>
mrvn: it can be a separate code path / hardware path. Actually I think on the routers I worked on, it would match a connected subnet mask in the route table
<mrvn>
obviously if one is 64bit and the other 128bit.
<immibis>
which was marked as a local route and triggered some different processing after that
<immibis>
conceptually you then go to the ARP/ND cache to see if you know the host's MAC address; if not then you buffer the packet and send an ARP/ND request; if you do then you just attach that MAC address
<immibis>
ARP/ND misses are handled by software. too difficult for hardware. and if we get more than 3 of those in a second or something we just drop the packet (!)
<mrvn>
ouch
<immibis>
tbf our product is not meant to be connected directly to servers. packets to directly connected machines are probably network management traffic
<mrvn>
so if I spam random packets at say 1000/s then no new ARP requests will succeed basically.
<immibis>
well that's assuming someone gave you access to the network management network
<immibis>
or the network operator configured it badly
<mrvn>
like every janitor has
<immibis>
yes, like every janitor has
<immibis>
just plug your packet spamming device in this port riiiight *opens closet* here
<immibis>
also the limit may have been 20, idk, it was pretty low
<immibis>
the good news is only ARP/ND cache misses get dropped so your packet spammer probably won't break any already-established connections
<immibis>
hardware fast-path routing goes as fast as the wires can carry packets
<mrvn>
immibis: they have these little boxes that plug into the TP port on a host and you plug the TP cable into the other side of the box.
<mrvn>
potentially a little USB patch cable for power
<immibis>
tfw no poe
<mrvn>
can't assume you always have POE
<gog>
gorgonical: are you changing perm bits to be more permissive
<gog>
that'll page fault
<immibis>
mrvn: so? what does the box do?
<gorgonical>
gog: no, it's during a memset
<gog>
are you sure you're not causing a page fault
<mrvn>
immibis: listens to all network traffic of the host and possibly filter or spam the line.
<gorgonical>
region 0xffffffd8000ddfff, counting down from 0xffffffd8000dfd3c to 0xffffffd8000dd000. However, qemu's `info mem` shows this: ffffffd800000000 0000000080200000 0000000007e00000
<gorgonical>
it's suspicious that it's page-aligned
<gorgonical>
that first adr is the faulting adr
<mrvn>
immibis: and it's basically invisible. Nobody notices such a little box at the back of the server.
<gorgonical>
unless this is allowed to have holes in this output
<gorgonical>
...
<mrvn>
immibis: Means you don't need access to the switch, any host connected to the switch will do as attack point.
<immibis>
mrvn: correct. I wish you great success taking down T-Mobile
<immibis>
sarcastically of course as I don't want to be an accessory to your crimes
<mrvn>
hah, no need. they take themself down often enough
<gog>
is the S bit showing
<gorgonical>
the attrs are rw--gad
<mrvn>
gorgonical: is that global, accessed, dirty or not-global, not-accessed, not-dirty?
<gorgonical>
it is global, accessed, dirty. but the mmu doesn't do anything with these in riscv
<gorgonical>
they are all os-controlled
<gorgonical>
The two dashes are, I think, x for execute and u for user
<gog>
oh
<gog>
riscv
<gorgonical>
yes sorry
<gog>
no worries idk anything about it
<gorgonical>
I understand lol neither do i
<gog>
lol
gildasio has quit [Remote host closed the connection]
<immibis>
mrvn: you know something impressive I saw in a demonstration once (recorded defcon presentation possibly)? Live demo: SPLICE this thing into a network cable and we feed the surveillance camera a loop, just like in Hollywood.
<bslsk05>
'DEF CON 23 - Van Albert and Banks - Looping Surveillance Cameras through Live Editing' by DEFCONConference (00:41:25)
<immibis>
the impressive part: do it with only a few milliseconds of service interruption
<mrvn>
immibis: lame. Do it without.
<immibis>
mrvn: for that you'd have to delve deep into ethernet signal processing. It should be possible without interruption on 100Mbps ethernet, which nobody uses any more
<immibis>
gigabit, dunno.
<mrvn>
immibis: open up the cable and clip two connectors on each wire going into your device. Set the device to just pass through the signals and then cut the wires between the two clip-ons. After that you can switch to intercepting the signals inbetween ethernet frames.
<immibis>
mrvn: yes that's literally what they did, but the remote PHYs have to renegotiate something with the interceptor device PHYs
<immibis>
only for gigabit+
<mrvn>
immibis: hmm, maybe. A good PHY can probably work with existing values reasonably well.
<immibis>
the echo cancellation means you can't separate out the signals travelling in each direction, or something like that
<immibis>
probably with enough effort you could make it seamless
<immibis>
not with off-the-shelf parts
<mrvn>
Do you care which direction the data goes? Each packet has src/dst.
<immibis>
Yes, you do, because without separating the two directions you can't decode ANY data
<immibis>
at the level you are currently talking about there are no "packets", just a stream of symbols
<immibis>
oh if you didn't click on the youtube link, it is a video of a live demo they did at defcon
<immibis>
they spliced a network cable live
<mrvn>
watching
<immibis>
in front of an audience
<mrvn>
"everybody who cheared is a FED"
<clever>
that reminds me of another defcon talk, on the dangers of thunderbolt ports
<clever>
they took a thunderbolt to dvi adapter, gutted it, and then just passed a thunderbolt cable thru the empty case
<clever>
and glued it back together, along with the hollowed out case of a dvi cable end
<clever>
to the un-educated, thats a thunderbolt->dvi adapter, and the pcie dma attacks are moot
<clever>
on the far end, was an external pcie box doing dma attacks, daisy-chained to a real dvi/dp adapter
SGautam has quit [Quit: Connection closed for inactivity]
<immibis>
so they made something that looked like a DVI cable but was actually thunderbolt... you'd still have to trick someone into using your (apparent) amalgamation of cables without pulling them apart
<immibis>
and if they're doing that, why not do it the regular way and put some malicious stuff inside the dvi/dp adapter case?
<zid`>
isn't that what it's a demonstration of
<zid`>
just without making it on 40 nanometer
<immibis>
possibly but then why bother making it look like a DVI cable
<immibis>
if you're trying to demonstrate a thunderbolt attack you can just plug a duct taped black box with RGB skull and crossbones into your thunderbolt port and it still gets the point across
<clever>
immibis: they left this adapter cable on the podium for the defcon talks
<clever>
and the guy that did the previous talk used it :P
<immibis>
oh, defcon :P
<clever>
who's going to question a con supplied adapter for the projector rig?
<clever>
it was less about the dangers of thunderbolt, and more about how you can be fooled into thinking those dangers are gone
<zid`>
you've got to trust *some* infrastructure at defcon else you can't really *give* a talk
<doug16k>
can't wait until the mitigations are so good, I can stab at my motherboard with a screwdriver and it won't be vulnerable
<clever>
zid`: yep
<doug16k>
thunderbolt attack is one step away from being at board with screwdriver
<immibis>
zid`: bring your own whatever to VGA condom, but you're still trusting the stage to not be a hidden trapdoor over a pit of alligators
<zid`>
vga has i2c
<zid`>
for doing edid etc
<immibis>
hence the condom
<zid`>
how does that work?
<immibis>
well you disconnect the I2C lines. same as a USB charging condom
<zid`>
and if the other end refuses to work with no edid?
<zid`>
you either don't present
<zid`>
or you submit to the attack
<immibis>
isn't it one-directional? you force your computer to output 1920x1080 regardless of EDID
<clever>
zid`: edid just tells you what resolutions the projector supports
<zid`>
THAT is my point
<clever>
so you can just guess, and hard-configure the video port
<zid`>
and if the other end refuses to work with no edid?
<immibis>
there's no projector that's going to refuse to work if it's not queried for EDID first
<clever>
zid`: thats not how edid works
<zid`>
and if the other end refuses to work with no edid?
<immibis>
you mean the laptop end?
<zid`>
no
<clever>
edid is just an i2c eeprom
<immibis>
you mean the projector end?
<immibis>
<immibis> there's no projector that's going to refuse to work if it's not queried for EDID first
<zid`>
okay, but
<zid`>
and if the other end refuses to work with no edid?
<immibis>
the intended usage of EDID is you just query the display to see what the display supports
<immibis>
zid`: then it's malicious
<zid`>
TADA
<zid`>
IT@S FUCKING DEFCON
<immibis>
zid`: we are talking "someone smashed the projector with a hammer" levels of malicious now
<immibis>
DoS is trivial
<zid`>
<zid`> you've got to trust *some* infrastructure at defcon else you can't really *give* a talk
<immibis>
yes like I said you have to trust the stage is not a secret trapdoor over a pit of crocodiles
<gorgonical>
gog: holy crap I know what it is lol
<zid`>
so yes, people shouldn't fuck with the stage.
<clever>
i would trust that my drivers are hardened against parsing bugs in the edid handlers
<clever>
so hdmi/vga/dvi/dp, i would just trust
<immibis>
clever: then you'd be a fool
<gorgonical>
it's the page tables
<gorgonical>
bruh
<gorgonical>
how is this happening lol
<zid`>
gorg what did you do
<gorgonical>
I have no idea how this happened lol
<immibis>
hey I wonder if a more precise USB killer could do a fault injection attack
<jjuran>
This is why I use a RPi as a display adapter
<immibis>
without frying the USB port chips
<zid`>
more riscv stuff, setup the page tables wrong and hit a boog by the sounds of it?
<gorgonical>
anyway it looks like the bootmem allocator finds a "free" spot which happens to be exactly where the page tables are. so the memset naturally explodes all sorts of fun stuff
<gorgonical>
yep
<clever>
jjuran: that reminds me, the GUD drivers let a pi-zero act as a usb->hdmi adapter
<gorgonical>
Clearly I'm not reserving the right range if it's just blowing away the pts
<jjuran>
clever: Is that work that you did?
<immibis>
wouldn't qemu tell you the page tables were corrupted? wasn't that the point of "info mem" or whatever command?
<clever>
jjuran: nope, just something i discovered
<clever>
jjuran: the main implementation runs under linux, along with the official firmware
<clever>
ive been wanting to make a more reduced one, but i dont have hdmi init yet
<bslsk05>
github.com: Home · notro/gud Wiki · GitHub
<clever>
under gadget implementations, is a list of things that can act as a display
<zid`>
are page tables ever corrupted?
<gorgonical>
immibis: I don't think I was running info mem right before the corruption
<zid`>
I suppose they could be on riscv
<zid`>
I think on x86 every bit is meaningful
<gorgonical>
Just at the start of the memset. So as it zeroes from back to front it runs into a part of the pts
<gorgonical>
At the very least it shouldn't be handing out these parts of memory anyways
<gorgonical>
zid`: there are some internal bits that are only meaningful to the OS
<gorgonical>
but not at the ends of the entry
<zid`>
no idea what that means
<zid`>
I was asking if it was possible for a page table to be corrupt
<gorgonical>
corrupt in the sense that they aren't doing the right thing anymore because I'm willy-nilly changing them
<immibis>
zid`: well they don't contain what's meant to be in them
<immibis>
"you talk about corrupting memory, but how can the memory be corrupt if every bit is still a 1 or a 0?"
<zid`>
no I mean actually corrupt
<zid`>
such that `info mem` or whatever would notice
<gorgonical>
I can at least test this now
<zid`>
[22:37] <immibis> wouldn't qemu tell you the page tables were corrupted? wasn't that the point of "info mem" or whatever command?
<zid`>
So the response is, "can they even BE corrupted?"
<immibis>
oh I just mean it would tell you the page was unwritable or whatever
<zid`>
I read it rather literal
<zid`>
ly
<gorgonical>
yeah it looks like the pts get fucked up
<gorgonical>
now qemu prints nothing for pts lol
<mrvn>
zid`: there are usualy some AVL bits (available)
<mrvn>
zid`: the one bit the "info mem" should notice is Present
<mrvn>
physical addresses outside available ram it could notice too
<immibis>
will those cause a page fault? I don't think so
<mrvn>
Present not set would page faultr
<clever>
immibis: ~12mins into that defcon link you posted, they have the gigabit running thru 2 parallel paths temporarily
<gorgonical>
not reserving the bss segment lol
<clever>
immibis: i think that will mess with the eye diagram some, and could fail a cable analyser
<gorgonical>
but how though
<clever>
but once you cut the cable and go thru the relays, that stops, and you become more invisible like he claimed
<mrvn>
the difference in path length should be minimal
<clever>
mrvn: depends on how much slack you have between the 2 punchdowns
<mrvn>
Would you get extra reflections from signals going in a loop around both paths?
<clever>
yeah, i think you would
<clever>
but you would need an analyser to confirm
jjuran has quit [Quit: Killing Colloquy first, before it kills me…]
jjuran has joined #osdev
coso has quit [Quit: Leaving]
<gog>
I'm in ur page tables corruptin ur memory mappings
<clever>
immibis: ~18mins, that reminds me of how my tv service works, h264+mp3 over mpegts over rtp over udp over multicast ip!
<zid`>
I'm in ur sawayama solitaire
<zid`>
getting my ass kicked
<immibis>
mrvn: kinda. I think it's more like an impedance discontinuity
<immibis>
which does cause reflections back and forth
<clever>
yeah, i think there will be 2 different distotions
<clever>
the impedance mismatch will cause some relfections, but the dest will also receive 2 copies of the signal, with a slight delay
<clever>
so the edges will be less well defined
<mrvn>
Don't set up the tap while they test the wires and you are good
<clever>
yeah
<clever>
i think the main point, is that after they have installed it, and cut the excess wire, it becomes invisible, when in passthru mode
<clever>
so you could leave it there for years
<geist>
zid`: what happened to zid?
<clever>
there is a comment that agrees with me
<clever>
> It depends. The generic $100 ones you'll see many self-employed contractors use wouldn't see a difference. The test kits we lug around on a cart at work get fussy if we untwist the wires before terminating them.
<clever>
~32mins in, vim, now thats cool! :D
<zid`>
geist: killed him and stole his skin
<zid`>
the ` is to represent how the flesh does not sit perfectly on my skeleton
<zid`>
That, and libera was netsplitting yesterday.
<klange>
restarted my rpi after several months
<klange>
it was still ticking along, three months of uptime, but I wanted my serial console back...
<gorgonical>
for some reason the linker is putting stuff after my _end symbol
<clever>
gorgonical: the .map file sometimes answers why
<clever>
-Wl,-Map=build/bootcode.map
<clever>
it lists off every section its processing in order, and then double-check if the sections are in the linker script
<gorgonical>
does this spit out something other than the system.map?
<gorgonical>
I'm not familiar with this -Map option
<bslsk05>
pastebin.com: OUTPUT_ARCH(riscv)ENTRY(stext)/*jiffies = jiffies_64;*/PHDRS { text PT_L - Pastebin.com
<gorgonical>
And that's the vmlwk.lds
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
<gorgonical>
There's an .sbss section that isn't specified anywhere in my makefiles
<heat>
your linker script should have a .sbss
<gorgonical>
Isn't it just a secondary bss?
<heat>
and then you're supposed to put $__global_pointer near it
<heat>
no, it's a bss for small objects
<gorgonical>
oooh
<doug16k>
it's "short" bss - close to something
<gorgonical>
is this part of riscv or something?
<heat>
yes
<gorgonical>
Thank you
<heat>
well, part of the toolchains, probably not part of the ABI
<heat>
the point being that you put $__global_pointer somewhere in the middle and then every access to those many, small objects gets relaxed
<heat>
usually + 0x800 IIRC
<gorgonical>
oooooh
<gorgonical>
I see. this is because pc-relative loads are faster right
<gorgonical>
1 fewer insn?
<doug16k>
architectures that have some preferred area that is easy to access would have it
SpikeHeron has quit [Quit: WeeChat 3.5]
<doug16k>
smaller encoding or something along that line
<gorgonical>
Okay. I'll have to read more about this
<heat>
I can't remember how gp works
xenos1984 has joined #osdev
<heat>
not something I ever had to look at
<clever>
the official rpi firmware also makes heavy use of gp, i think another benefit is less patching when you relocate the binary
<clever>
but the vc4-gcc fork doesnt even touch gp, and just uses pc-rel or absolute everywhere
SpikeHeron has joined #osdev
<doug16k>
ia64 has gp - can pack a 22-bit offset into instructions, has .sbss
<doug16k>
and .sdata, same idea
<doug16k>
I think of it as "short" because it is a shorter range encoding, but it can be called "small" because linkers use a simplistic strategy of putting small objects there and bigger ones in the far away bss/data
<heat>
IA64 is the best
<heat>
peak cpu architecture
<doug16k>
also, compiler can "just know" whether it can use short encoding because it knows it is small enough to land in sbss/sdata
<mrvn>
that assumes you don't have too many small objects. Only the linker can really know how far something is.
<doug16k>
if your code is so nuts it has 4M globals, then you can usually use a compiler flag to tell it to use the pessimistic model
<mrvn>
What you should do is go through the obejcts files and collect objects till code + data + bss reaches 22-bit offsets and then dump them. Then keep going with the remaining objects.
<mrvn>
Dump anything not referencing things into any holes.
<clever>
the VPU allows a 32bit offset from gp, so you can be far dumber
<mrvn>
clever: and only has 1GB of memory, or 30bit.
<clever>
the assembler will automatically pick an encoding that uses the least bits, based on how big the offset is
<clever>
mrvn: yeah, but the top 2 bits are cache control flags
<clever>
though, gp + offset, over 1gig, doesnt make sense
<clever>
addition would wreck the flags
<mrvn>
why? you might want to access something with different flags
<mrvn>
You know where gp is so you can compute an offset that results in the right flags.
<clever>
if you dont know the old flags, then addition will leave to undefined flags
<clever>
you need to clear the top 2 bits, then OR some in
<clever>
or assume the gp has known flags
<mrvn>
I assumed the last :)
<clever>
the official firmware limits itself to a ~16-20mb region by default