<mcrod>
this is the protocol driving almost every vending machine in the US
<Ermine>
gog: may I pet you
<gog>
Ermine: yes
<sham1>
Nonsense APIs are a fact of life sadly
<gog>
i should go to lunch i'm hungry
<sham1>
Hi hungry, I'm sham1
<gog>
i'm half working on a new flow for this type of transaction and half trying to shoehorn the existing flow in and seeing how it falls together lol
<gog>
i got the first step working, the question is how to make the second step work
<gog>
i think that's a good stopping point for the moment
dutch has quit [Quit: WeeChat 3.8]
* Ermine
pets gog
<mjg>
nothing speaks garbage like financial services
<Ermine>
huh?
dutch has joined #osdev
<mcrod>
financial anything has some really bad tech
<mcrod>
which is incredible, and terrifying
<gog>
what's sad is the payment processor we use merged with a better company and made their product worse
<sham1>
I finally got my physical paper for my BSc
* bnchs
purr
<mcrod>
sham1: should we clap
* mcrod
clap?
<sham1>
Nah
<mcrod>
;(
<mcrod>
:(
truepassion has joined #osdev
<mjg>
clap is not a joke
<truepassion>
hi, on aarch64, is it possible to have EL0 and EL1 use the same TTBR?
<truepassion>
i.e. to not have page table isolation
<heat>
that's not page table isolation
<truepassion>
heat: i see, then what is page table isolation in aarch64?
<heat>
page table isolation = only the bare minimum is mapped (trap entry points) and everything else gets "mapped" after you entry into the kernel
<truepassion>
heat: right but in arm64, is kernel memory mapped when the CPU is in EL0?
<heat>
that could mean having shadow kernel page tables or, on arm64, i've seen a trick where you take TTBR1 and set its size to the smallest (30-something-bits) and then on entry you expand that to the full address space
freakazoid332 has joined #osdev
<heat>
you need to have *some* memory mapped, but not all
<truepassion>
i see...
<heat>
so page table isolation basically means you take only the bare essential and only map that
<heat>
so the trap entry code and whatever data you need to switch to the full kernel MMU context
<truepassion>
when cpu is in EL0, it uses ttbr0 and not ttbr1. doesn't that ensure page table isolation?
<heat>
because the arm64 mmu is stupidly complex AFAIK it's relatively possible to enable a very low overhead PTI
<heat>
that's not true
<heat>
ttbr0 and ttbr1 have nothing to do with EL0/1
<heat>
if TTBR0 and TTBR1 are both enabled, you can touch them/execute on them/whatever from EL0 OR 1
<heat>
that has nothing to do with permissions
<heat>
like in practice TTBR0 and TTBR1 both expand into a full two-half 49-bit address-space
<truepassion>
you mean EL0 can try to speculatively access VA starting with high bits set to 1s and hence fetch data using ttbr_el1?
<truepassion>
ttbr1**
<heat>
yes, that's why you need actual PTI tricks like the one I described
<truepassion>
gotcha
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<heat>
arm64 having two halves is actually a blessing
<truepassion>
in what sense?
<heat>
i.e there's no need to sync kernel mappings across all process page tables because there's a single kernel page table
<truepassion>
right
<heat>
and given TCR address space size crazyness you can have PTI without actually invalidating your kernel's TLB
<heat>
and even if you did traditional KPTI using shadow page tables, you would only need a single shadow page table, not one for each process
<truepassion>
"and given TCR address space size crazyness..." is that how you meant that arm sets size of ttbr1 to smallest (30-something-bits)?
<heat>
yes
<truepassion>
thanks for explaining!
<heat>
iirc this is how darwin/XNU does the KPTI trick
<heat>
i'm personally not aware of how linux does it
<truepassion>
i see
<heat>
on arm64 that is
<truepassion>
is there a doc i can read about KPTI in arm64?
<heat>
not really
<heat>
you can look at the mmu docs and try to figure things out for yourself, or read the sauce
<bslsk05>
kernel.googlesource.com: kpti-base - pub/scm/linux/kernel/git/arm64/linux - Git at Google
<heat>
linux has a regular shadow page table
<truepassion>
right... that patches talk about mapping a kernel trampoline to handles exceptions from el0
zxrom has quit [Quit: Leaving]
slidercrank has quit [Ping timeout: 245 seconds]
zxrom has joined #osdev
sinvet has joined #osdev
<truepassion>
heat: so linux uses a trampoline page which EL0 will trap into before mapping in kernel proper and jumping into it? is that what you call shadow page table?
<zid>
I asume the "mapping in the kernel" part is equivalent to a cr3 swap on x86?
<heat>
so linux has two page tables, one with the trampoline mapped, which EL0 will trap into and switch to the proper kernel page tables
<heat>
any trap coming from EL1 will not need to switch page tables as you're in the kernel already
<heat>
the switch is as simple as "take ttbr1_el1, get the swapper_pg_dir from it, set ttbr1_el1 to swapper_pg_dir + kernel ASID"
<heat>
the concept is similar-ish to x86 shadow page tables where each address space (there you only have one "TTBR") has two top-level page tables, but only one of them has interesting stuff mapped
<heat>
arm64 has it a lot simpler since you don't need to do things like propagate top level page table changes on both the shadow pt and the user pt
nvmd has joined #osdev
<heat>
arm64 can literally just do "have a region where only the trampoline and its data is mapped, and keep it mapped on a separate page table"
<heat>
or the aforementioned T1SZ trick
<heat>
which one is faster? I would blindly guess XNU's T1SZ trick, but since linux went with 2 page tables + proper ASID, it probably means that the double-pt method is faster
<truepassion>
heat: XNU T1SZ trick limits kernel address space when CPU is executing in EL0?
<heat>
yep
<heat>
i.e imagine you set T1SZ to 32, you reserve the first 4GB of kernel address space to the trampoline, anything important goes after that, hence unmapped from EL0's PoV
<heat>
then in the trampoline you just expand it to 48
<heat>
that feeling when you hardcode private details of the crypto algo just so you can poke it from your *FUCKING FILESYSTEM*, then call the crypto function wrongly so your "CRC32c" is not actually a CRC32c
<heat>
mjg, funny freebsd detail: calculate_crc32c does it wrong
<heat>
in freebsd you can't trust man pages, comments, and now function names
<zid>
I like crc8, "What polynomial do you use?" "7"
<mjg>
have you vrified this generates different values than whatever reference implementation
<heat>
yes, trivially, by checking the call sites on ext2fs
<mjg>
?
<heat>
i could plug it into my crc unit tests but given I get the exact binary opposite of calculate_crc32c in an ext4 driver context, and my crc32c impl is correct...
<zid>
heat is it a kirk or a seearsee
<heat>
seearsee
rnicholl1 has joined #osdev
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
rnicholl1 has quit [Quit: My laptop has gone to sleep.]
ih8win8 has joined #osdev
<ih8win8>
I'm trying to understand how relocations in ELF files are resolved. For rel relocs, do I extract the offset field from the instruction, then add that to the referenced symbol's value to get the final address?
<heat>
all relocations have well defined formulas in the architecture's ELF ABI docs
<ih8win8>
I have the doc for ARM, but I'm a bit confused. There's an addend field mentioned. For rel relocs, is this what's extracted from the instruction? For rela relocs, I assume this comes from the r_addend field of the reloc, and the field that's already in the instruction is ignore.
<zid>
yea that's what addend is supposed to mean, but we found tools randomly ignoring it or not recently on x86:P
<heat>
which arm? arm32 or arm64?
<ih8win8>
ARM32
<zid>
3 mins until honzuki mad-refresh-mode starts
rnicholl1 has joined #osdev
<ih8win8>
The bits in the instruction are completely ignored for rela relocations, right?
k0valski18891 has quit [Quit: Ping timeout (120 seconds)]
<heat>
yes
<heat>
it says "If the place contains an instruction, the immediate field for the instruction is extracted from it and used as the initial addend"
<heat>
i can't tell if this means the relocations always point to instruction boundaries, or if they point directly to imm fields
<zid>
x86 fills them with -2
<zid>
and just ignores it then adds -2
<heat>
probably easy enough to figure out using readelf
<zid>
no joke
<zid>
and by x86 I mean binutils
<zid>
3/4 of the tools at least do this
<ih8win8>
Because my linker is producing R_ARM_MOVT_ABS instructions (rela format with addend), but the immediate field in the movt instruction is already filled out with an actual address.
<zid>
just do whatever makes the math work and die happy?
<ih8win8>
haha, yeah that's the real way to make it work
<heat>
>die happy
<heat>
you're doing osdev, that's impossible
<zid>
I'm assuming you die in the effort
gxt__ has quit [Ping timeout: 240 seconds]
<zid>
during the 10 second window after you finish and it works
<zid>
before you notice the edge case that's impossible to fix
<zid>
and come crashing back down to reality
gxt__ has joined #osdev
<zid>
Ascendance of a Bookworm Part 05 Volume 05 PREPUB [8/8]
<zid>
later noobs
<gog>
hi
<heat>
gog
<gog>
heat:
<mjg>
gog: ey mate, have you seen DRAGON BALL?
<mjg>
Z or otherwise
<gog>
dragon deez balls
<gog>
but i've seen an episode or two
<gog>
never really got into it
<mjg>
:A
<mjg>
that is the standard for girlz
<mjg>
dbz in europe used to be almost a boys-only thing
<heat>
my favourite dragon ball z episode is the one where they deal with the ma situation
<mjg>
what
<heat>
ma balls
<gog>
i was pretty basic in terms of my anime watching
<gog>
cowboy bebop, evangelion
<mjg>
heat: do you have updog?
<heat>
gog, i got the boomer
<heat>
u proud??
* gog
pats heat
<gog>
good boy
<heat>
mjg, what is the definition of updog
<mjg>
same as dickfor
<bnchs>
hi gog
<bnchs>
can i pet
<gog>
yes
* bnchs
pets gog
* gog
prr
<bnchs>
good girl
<gog>
ee
ih8win8 has quit [Quit: Leaving]
<heat>
the 386 system v abi has X11 and motif definitions and i think that's beautiful
zxrom has quit [Remote host closed the connection]
rnicholl1 has quit [Quit: My laptop has gone to sleep.]