<kof123>
> What are the payoffs, what strategy should I choose. No one told me we're playing the game. the game is to never announce the game. the payoff is there are then no rules. the strategy is to not tell you this.
Yoofie5 has joined #osdev
adder_ has joined #osdev
adder has quit [Killed (NickServ (GHOST command used by adder_))]
adder_ is now known as adder
Whooa21 has joined #osdev
exit70_ has joined #osdev
skipwich_ has joined #osdev
k_hachig has joined #osdev
Brnocris1 has joined #osdev
<zid>
oopsie, I have 8k used-up uranium fuel cells in inventory.. need a *couple* more centifuges
pretty_dumm_guy has quit [Ping timeout: 256 seconds]
zid has joined #osdev
vdamewood has joined #osdev
edr has quit [Quit: Leaving]
Matt|home has joined #osdev
Matt|home has quit [Remote host closed the connection]
Matt|home has joined #osdev
joe9 has joined #osdev
<kof123>
> What are the payoffs you do you add er, but game theory is based on a competent/educated/literate/knowledgable/"wise"/etc. populace > game theory assumes that players are rational > cooperation between intelligent, rational decisionmakers
<kof123>
unity of opposites and the old "wise" is based on things sowing the seeds of their own destruction lol
zxrom has quit [Quit: Leaving]
gorgonical has joined #osdev
<gorgonical>
Man ubsan is really angry about access alignment
<zid>
I'd hope so
<zid>
given how incredibly UB that is
<gorgonical>
I hadn't considered that taking the pointer of a member could result in an unaligned pointer before
<zid>
Yea, malloc just returns things with "super incredibly good alignment" so that it never happens unless you do sketchy (illegal) things
<zid>
like type punning, or pragma pack etc
<adder>
kof123: Actually, there are two main branches of game theory. In one of them, you assume that the players do NOT communicate between themselves and otherwise make binding agreements, which leads to individual rationality (as opposed to collective). But yes, cooperation can yield better outcomes for everyone involved. This is why smart people ostracize the ones who don't cooperate, because they're lowering the outcomes for everyone.
<gorgonical>
ubsan is complaining seemingly about: cwq->run_depth--;, implying that both the cwq pointer is misaligned and then accordingly the run_depth member in it is also misalinged
<zid>
poor cwq
<zid>
have you tried.. aligning it?
<gorgonical>
Since cwq is a function parameter, that implies that whoever is passing it in is acquiring it from an unaligned address?
<gorgonical>
That could happen if you cast something to a the type of cwq, but if I just have an array of these somewhere or malloc one, that should be aligned, right?
<gorgonical>
But wouldn't that only cause the member access to be unaligned?
<gorgonical>
If I have struct whatever cwq; that should be aligned, right?
regreg has joined #osdev
Arthuria has joined #osdev
<zid>
yea, unless you fucked up your linker script
<gorgonical>
Right
<zid>
and unaligned a section with align n or whatever
<gorgonical>
And then I would expec to see a shitload more unaligned accesses
<zid>
why not.. look at the value of cwq?
<gorgonical>
Yeah I'm about to try that, just wrapping my head aroudn the error first
Arthuria has quit [Remote host closed the connection]
smeso has quit [Quit: smeso]
smeso has joined #osdev
adder has quit [Ping timeout: 255 seconds]
adder has joined #osdev
valerius_ has quit [Remote host closed the connection]
k4m1 has quit [Ping timeout: 255 seconds]
koolazer has quit [Ping timeout: 255 seconds]
koolazer has joined #osdev
valerius_ has joined #osdev
k4m1 has joined #osdev
Arthuria has joined #osdev
SunClonus has joined #osdev
SunClonus has quit [Remote host closed the connection]
Arthuria has quit [Remote host closed the connection]
regreg has quit [Read error: Connection reset by peer]
<gorgonical>
is the usbsan alignment reported in bytes or bits? I'm getting errors that things aren't order-6 aligned, which would be 64, but there's no way that refers to byte-alignment, right?
k_hachig has quit [Ping timeout: 260 seconds]
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
uzix has joined #osdev
uzix is now known as mahk
zetef has joined #osdev
zetef has quit [Remote host closed the connection]
gbowne1 has quit [Remote host closed the connection]
zetef has joined #osdev
goliath has joined #osdev
zetef has quit [Remote host closed the connection]
xenos1984 has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
xenos1984 has joined #osdev
GeDaMo has joined #osdev
knusbaum has quit [Ping timeout: 260 seconds]
gog has joined #osdev
nyah has joined #osdev
Brnocris1 is now known as Brnocrist
Whooa21 is now known as KitsuWhooa
netbsduser` has joined #osdev
nikolapdp has joined #osdev
heat has joined #osdev
Gurkenglas has joined #osdev
<heat>
<gorgonical> I hadn't considered that taking the pointer of a member could result in an unaligned pointer before
<heat>
it can't, unless the struct is packed or misaligned from the start
<zid>
welcome to line 2 of that conversation
<heat>
thanks
<vdamewood>
Okay... I feel old. /me unaligns heat
<vdamewood>
Oops
<vdamewood>
Half of that was meant for another channel
<zid>
you are old, dw
<heat>
who's heat and why is he on another channel
<vdamewood>
zid: AM TOO!
<vdamewood>
heat: Must be popular.
<ddevault>
but why does it crash ;_;
<ddevault>
GP fault on iretq only with KVM enabled (qemu softmmu does fine)
<ddevault>
first ISR is after jumping into userspace
<zid>
and your TSS.. exists and has rsp0 filled out?
<ddevault>
yep
<zid>
no idea what that paste means btw
<zid>
do they not have qemu in what
<ddevault>
it's just register dumps on each interrupt
<zid>
yea but qemu already does that
<zid>
and I know the format
<ddevault>
bug only occurs with KVM, where qemu's dump does not work
<zid>
ah lame
<ddevault>
also only occurs when booting via EFI
<ddevault>
(which is my current project, to add x86_64 EFI support)
<ddevault>
also only seems to happen on PIT interrupts? if I turn off preemption everything is fine, including stuff that hits other interrupts like page faults
<zid>
I only have a guide on how to be really cool
<ddevault>
but I don't think it's null, it looked to me like that RPL was wrong?
<ddevault>
it goes from RPL 3 (correct for userspace) to RPL 0 (which doesn't match the GDT, because this segment is, well, userspace)
<ddevault>
is that a plausible explanation?
<heat86>
0 is never a valid segment
<ddevault>
it goes from ss 0x1B to SS 0x18, which is 0b11011 and 0b11000, so the segment index remains the same (non-null)
<heat86>
How are you printing 0 then?
<ddevault>
where am I printing 0?
<ddevault>
oh, it's zero when the GP fault occurs
<heat86>
Your isr dump has ss 0
<ddevault>
I was looking at the return from ISR 32, which I think is more likely the origin of the problem (since that's the iretq that causes the GP fault)
jjuran has quit [Quit: Killing Colloquy first, before it kills me…]
<ddevault>
at the dump for the second ISR 32 you can see the state of the stack when the iretq is called, causing the GP fault
jjuran has joined #osdev
<ddevault>
where ss will be set to 18 upon iretq'ing, which if I'm reading the manual right could cause a GP fault because the RPL is now requesting ring 0
<heat86>
What, ISR 13 has the state on the iretq
<heat86>
And it has ss 0
<ddevault>
is it possible that ss is set to 0 when the iretq faults?
<heat86>
Whatever the other ISR 32 is (timer?) is the starting context
<heat86>
Uhhhhh... it might be
<heat86>
Actually, i'd wager it's likely... but you should check the SDM
<zid>
SS has some exceptions
<zid>
in the #GP part of the manual
<zid>
for like "SS must be non-zero" and stuff for certain things
<heat86>
Oh, error code 0x18, sounds like a bad iretq to ss 0x18?
<ddevault>
right, that's what I'm thinking
<zid>
and yea, gp error codes are selector numbers
<ddevault>
0x18 sets the RPL to 0, it should be 3
<ddevault>
it doesn't match the GDT's privilege level for this selector
<ddevault>
so that smells like the likely problem iiuc
<ddevault>
yes, happens at the same time every time
<heat86>
AMD or Intel?
<ddevault>
AMD
<heat86>
I vaguely remember that AMD had slightly different behavior wrt segments
<heat86>
Can you try Intel?
CutieMelo has joined #osdev
<ddevault>
no intel machines handy
<ddevault>
but I can hand you an iso?
<heat86>
Sure but you'll need to wait a couple of hours, if that's ok
<ddevault>
I wonder if the issue is from sysret
<ddevault>
lemme try modifying userspace to loop forever without making any syscalls
<heat86>
But you're not sysretting here
<ddevault>
yeah but I was wondering if sysret fucked up the stack selector
<heat86>
Is that not an ok stack selector?
<ddevault>
aha, yes, this seems likely
<ddevault>
no, the RPL is wrong
<ddevault>
making userspace loop forever without performing any syscalls prevents the GP fault from recuring
heat has quit [Remote host closed the connection]
heat has joined #osdev
pretty_dumm_guy has joined #osdev
<ddevault>
yep, that was it, IA32_STAR needed to have the RPL bits set for the SYSRET selector
<ddevault>
all tests passing with EFI & KVM :D
<zid>
IF (CPL ≠ 0) THEN #GP(0); FI;
bauen1 has quit [Ping timeout: 264 seconds]
<zid>
that's s upposed to be notequal but my font didn't have it
<GeDaMo>
≠
<zid>
I don't see an ss related fault
<ddevault>
well, ss was the problem, so
<zid>
the hw even does
<zid>
SS.Selector := (IA32_STAR[63:48]+8) OR 3;
<ddevault>
well, it skipped the OR 3 part for me, it seems
<zid>
then just sets ss.base = 0; ss.limit = fffffh hardcodedwise
<zid>
without loading from the real descriptor
<zid>
The only GP is non-canonical rcx, not in ring0 when running sysret
<ddevault>
the GP does not occur in sysret
<ddevault>
sysret sets up a state which causes a GP to later occur at the next iretq
<zid>
ah yea, iretq can fault for a billion reasons
<ddevault>
setting RPL to 3 in the sysret selector in IA32_STAR fixes the issue
<ddevault>
I see that OR 3 thing in the sysret code as well, but
<zid>
I assume that just means
<ddevault>
fwiw the AMD manual tells you to set these bits to 11b in IA32_STAR, so
<zid>
that it ends up having a 3 again when you *push it*
<zid>
so that iretq sees the 3
<zid>
iretq doesn't do | 3
<ddevault>
right.
<ddevault>
anyway, hooray, it works
<zid>
my selectors are hardcoded, I literally just push 0x18
<zid>
or 0x21
<ddevault>
can't test on real hardware until I implement something with GOP
<zid>
etc
heat86 has quit [Ping timeout: 250 seconds]
<ddevault>
yeah, I could hardcode them, I guess
<ddevault>
or I guess I could try skipping ExitBootServices and route the kernel log through EFI with interrupts disabled and the lower half identity mapped...
<ddevault>
but not really worth it just to see if this works on my laptop
navi has joined #osdev
heat61 has joined #osdev
heat61 has quit [Client Quit]
heat has quit [Remote host closed the connection]
heat has joined #osdev
Gurkenglas has quit [Quit: Client closed]
Gurkenglas has joined #osdev
knusbaum has joined #osdev
Gurkenglas has quit [Client Quit]
vdamewood has quit [Quit: Life beckons]
junon has joined #osdev
<heat>
i'm home baybeh
<heat>
now i'm wondering what that difference between amd and intel is
<heat>
because there is one, i remember talking about it with geist, but it's somewhat subtle
bauen1 has joined #osdev
<mjg>
there was some shit on return to userspace
<mjg>
i think stack-related
<mjg>
you had to check for user trying to fuck you on intel
<mjg>
past that i don't know squat
<heat>
but that's errata IIRC
<heat>
i'm talking about a real, discrete difference in behavior that's totally specified and you can easily miss it if you read just one of the manuals
<mjg>
wdym errata
<mjg>
it was not a bug, just a difference, which unaccounted for resulted in a security problem
<mjg>
oh it's not stack, it was rip
<mjg>
* If the user-supplied value of %rip is not a canonical
<mjg>
* execute in ring 0 with the user's %gs and %rsp which would
<mjg>
* address, then some CPUs will trigger a ring 0 #GP during
<mjg>
* the sysret instruction. However, the fault handler would
<mjg>
* not be safe. Instead, use the full return path which
<heat>
there was also a pop ss bug
<mjg>
* catches the problem safely.
<mjg>
anyway there are probably "legit" differences indeed, but i don't know any
<mjg>
from semantics pov
<heat>
oh there's tons of errata when it comes to that non-canonical crap
<mjg>
again the above is not cpu errata
<mjg>
as far as i know
<mjg>
errata is for shit like the cpu hanging or giving wrong results
<heat>
ah i see, sysret works differently for amd and intel
<heat>
but i do know there was actual errata when it comes to this
<mjg>
i'm sure there was a bunch of actual errata in the area
<mjg>
but i mostly know about constant ways to get the wrong gs
<mjg>
swapgs probably saved silicon
<heat>
FREDFREDFREDFREDFRED
<mjg>
but fucked people hared securityw-sei
<mjg>
wise
<heat>
fwiw i think fuchsia sidesteps some of these issues by not letting you enter some of those weird edgecases
<heat>
like you can't map the last page of canonical address space, and their debug stuff doesn't let you set RIP to non-canonical, etc
<mjg>
how is that achieved
<mjg>
say i exploited a prog, now i have arbitrary code execution in that sucker
<mjg>
now what
<clever>
mjg: i saw an article before, about how the playstation(3?) used an old webkit and had such an exploit, and the browser was even running as root!
<clever>
(in a freebsd jail, so you couldnt do anything)
<gog>
the difference is that amd is better
<mjg>
then you could still execute arbitary asm
<gog>
RRRRRRRRRRRRRRYZEN
<gog>
the three R's: ryzen, rust and return-to-libc
<mjg>
gog: x86 is a shite arch which should have never taken off
<mjg>
gog: rust has 0 cost return to libc attacks
<gog>
they were in the right place at the righ time for the market really
<mjg>
ddevault: these ::'s are very concerning, are you c++ or rusting it?
<ddevault>
hare, of course
<nortti>
is that with the new x86_64 EFI bootloader?
<ddevault>
yeah
<ddevault>
on my starlabs starbook mk4
<nortti>
neat
<gog>
mjg: i'm slacking off rn
<gog>
ssshhh he's here
<nortti>
oh yeah, actually, I've been looking into hare a bit, and I noticed there's no 32-bit support yet. afaiu it seems to mostly be down to QBE – is this something I should work on QBE upstream, or is QBE itself intentionally non-32-bit-compatible?
edr has joined #osdev
<nortti>
(I was looking at using it on ppc32be, but it probably makes sense to port to 32-bit x86 first)
<nikolapdp>
nortti: qbe upstream is happy to accept patches for 32 bit architectures
<ddevault>
^
<ddevault>
and hare support for 32-bit targets would require some work, mostly in the compiler
joe9 has quit [Quit: leaving]
pretty_dumm_guy has quit [Ping timeout: 264 seconds]
pretty_dumm_guy has joined #osdev
<Ermine>
I hope I'll be able to attend qbe course in my uni in the next term
<nikolapdp>
i hate that almost all of the focus in my compiler course is on parse which is more or less a solved problem, rather than on the language design or code generation
<nortti>
qbe course as in, a compilers course done using qbe, or a course more focused on qbe itself?
<Ermine>
more of the former
<heat>
<mjg> say i exploited a prog, now i have arbitrary code execution in that sucker
<heat>
the heck do you mean
<heat>
i'm just telling you the kernel doesn't let you enter some of those weird edgecases in the entry/exit code, so you don't need to handle it
<mjg>
how
<heat>
you can't ever get a non-canonical IP through execution
<heat>
their mmap doesn't let you map the last canonical page, so you can't "naturally" fall through to non-canonical IPs, and the debug syscall that poke thread state just reject non-canonical too
<heat>
(or at least that's my understanding of it)
<mjg>
aight
<heat>
and if you do something like "mov $non_canonical_addr, %rax; jmp *(%rax)" you'll just page fault and never return
<heat>
they're clever, obvious hacks and i really don't understand why linux (et al) does not do this
<heat>
unless ptracing POKE_USER to a non-canonical IP is somehow a really great feature that shall not be broken
<mjg>
is that of consequence with fred?
<heat>
what is?
<mjg>
people fucking with their initial state before issuing syscall
<mjg>
or other traps
<heat>
i don't know, i would hope they finally got their shit right
<heat>
i think the stack switching and swapgs hacks aren't a thing anymore at least?
<heat>
but FRED is unobtanium, even in qemu TCG, so i haven't bothered learning all about it
<mjg>
you know
<mjg>
if netbsd was a real lolOS
sbalmos has quit [Ping timeout: 272 seconds]
<mjg>
fred is something they would implement ahead of linux
<mjg>
specifically cause you can't use it atm
<mjg>
instead they tinker with the other end
<mjg>
obsoletium
sbalmos has joined #osdev
goliath has quit [Quit: SIGSEGV]
<heat>
netbsd would be the only OS to support both VAX and CXL
k_hachig has joined #osdev
k_hachig has quit [Ping timeout: 255 seconds]
<kof123>
> Intel has sent these patches out early and well in advance of any CPUs being released with FRED to allow sufficient time for review and inclusion upstream before (ideally) shipping products
<kof123>
well, intel does not see netbsd as a target perhaps
<heat>
there's literally no way to test them without intel's freeware simulator
<heat>
not even *qemu*
<kof123>
i'm assuming i found the right fred...Dec 20, 2022 for the above quote btw lol
<kof123>
which i am not criticizing just.....grab a snickers?
<heat>
i know, i'm not upset at you, i'm upset at intel
<heat>
i wonder if even fbsd got patches
k_hachig has joined #osdev
<mjg>
lol
<heat>
doesn't seem like it. note to intel: please don't name future features like, err, persons
<mjg>
my legs are killing me
<gog>
did you do leg day
<gog>
i did cardio day
<heat>
stomach day
<heat>
i'm getting an mri for my shoulder, it's kind of fucked (since... ever?)
<mjg>
gog: for the past month i somehow end up walking about twice as much as i normally do
<mjg>
while the norm is already way past 10k steps
k_hachig has quit [Ping timeout: 264 seconds]
<netbsduser`>
nikolapdp: this is an old problem of compilers courses
<nortti>
geist: looking at the risc-v vector extension, it seems to permit an implementation with VLEN = ELEN = 8. other than software out there already being written to use FD extensions, do the non-vector floating point extensions provide value for implementations over minimal-viable vector extension (by e.g. being much smaller to implement or such)?
<heat>
does the V extension include floating point at all?
xenos1984 has quit [Read error: Connection reset by peer]
<heat>
i had the impression it was SIMD only
xenos1984 has joined #osdev
<nortti>
oh, I see, "Vector floating-point instructions require the presence of base scalar floating-point extensions corresponding to the supported vector floating-point element widths."
<nortti>
so a core with vector floating point impl but no FD would be nonconformant
<bslsk05>
github.com: lwan/src/lib/lwan-config.c at master · lpereira/lwan · GitHub
<nikolapdp>
you're doing goto *var which is nonstandard actually
<nikolapdp>
does clang even implement that
<acidx>
yes, clang has computed goto
<nikolapdp>
huh didn't know
<acidx>
no need to use computed goto, could use the switch/case thing that tatham uses. not really much of a difference
<nikolapdp>
guess so
<acidx>
the parser, linked in lwan-config above, will call the lexer to pull tokens from the file -- the lexer may generate a few more tokens, which are stored in a ring buffer, and consumed until it needs to read more characters from the file.
<acidx>
it kinda works like two coroutines working together, even though it's not really that
<nikolapdp>
i mean it is conceptually
<acidx>
yeah, in a way
<nikolapdp>
and it's perfectly portable, in the switch case
<acidx>
there are stackfull coroutines in this project too, but they're used for http connections and loops in the template engine
<acidx>
and it's pretty much not portable :)
<nikolapdp>
heh yeah
<acidx>
but it gives some really cool possibilities, like being easy to yield to the event loop regardless of the call stack depth
<nikolapdp>
yeah that's really the neat part of coroutines
pretty_dumm_guy has quit [Ping timeout: 272 seconds]
<bslsk05>
github.com: lwan/src/samples/asyncawait/main.c at master · lpereira/lwan · GitHub
<acidx>
doesn't require a bunch of callbacks and whatnot -- the async read function will essentially do a non-blocking read, and if it would block, it just yields to the event loop so the next coroutine is resumed
<acidx>
but the http handler function, as far as it's concerned, is making a blocking call
<adder>
Did you implement the async runtime yourself?
<acidx>
yeah
<adder>
Woah. That's some next-level programming. Good job. :)
<nikolapdp>
adder it's just a few instructions to save the registers and the stack to one struct and load from another
<nikolapdp>
not that hard
<nikolapdp>
just very non-portable
<acidx>
ah, the coroutine part isn't that hard, the hard part was to get async stuff to work :)
<nikolapdp>
acidx: very cool
<adder>
I watched David Beazley implement a toy async runtime in Python and that stuff is far from trivial to me.
<acidx>
but, thanks. :)
<nikolapdp>
yeah :)
<nikolapdp>
async c api is kind jank from what i remember
<acidx>
one day I'll probably write a blog post about how async stuff works in this project
<nikolapdp>
heh nice
<adder>
That'd be a very cool read.
<acidx>
it's not as advanced as you'd see in more generic stuff found in any language runtime though
<nikolapdp>
wait what's your blod
<nikolapdp>
blog
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<acidx>
but it was sufficient to implement what I needed (for instance, fastcgi support is built on top of that)
<bslsk05>
github.com: lwan/src/lib/lwan-mod-fastcgi.c at master · lpereira/lwan · GitHub
<zid>
yea php might use a *bit* of it? afaik apache literally has mod_php.so
<zid>
that does any of the fastcgi bits ita ctually uses
<zid>
and maybe php.exe does some of the heavy lifting *too*
<acidx>
mod-php embeds php in apache, doesn't really use fastcgi or whatnot
<zid>
The main cool part about fastcgi isn't even the less-shitty env setup, it's that you can multiplex connections, so you don't need to spawn a process per connection (a requirement for apache)
<zid>
so you can do rad shit like apache2 -> logind, which *stays resident* and has a database connection to the userdb open, taking user and pass. Then once you're logged in, you can just fork/exec yourself into game.exe or whatever, with stdin/stdout as the socket
<zid>
and now logind doesn't need to restart a billion times, you can do load balancing, whatever
<zid>
*that's* what's fast about fastcgi
<zid>
web people don't care about perf, they just throw machines at the problem
<nikolapdp>
can confirm
<nikolapdp>
absolutely
<zid>
Oh my god they were roommates
<nikolapdp>
who
<zid>
meme fail
<nikolapdp>
dang
Yoofie has quit [Read error: Connection reset by peer]
Yoofie has joined #osdev
knusbaum has joined #osdev
exit70_ is now known as exit70
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Turn_Left has quit [Read error: Connection reset by peer]
k_hachig has joined #osdev
navi has quit [Quit: WeeChat 4.1.2]
k_hachig has quit [Ping timeout: 255 seconds]
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]