#EvalynOS

1 messages · Page 7 of 1

hazy saddle
#

For USB I might have USB mass storage and USB keyboard and mouse in kernel

#

But other usb drivers would be userspace

#

And userspace will have a way to send and retrieve whatever it wants to usb ports

hazy saddle
#

So you can boot from USB and have usb input always without depending on userspace

devout path
#

noicee yeah that woudl be nice

#

im close to giving up

#

i swear

#

aaaaaaaaaaaaaaaaaaaaaaaaaa

hazy saddle
#

aaaaaaaa

#

Do
You have your collage friends that can look at this crap?

devout path
#

they're all in vacation

hazy saddle
#

Damn

#

Honestly @devout path

#

Do you wana just rewrite this from scratch?

#

And put this commit to shreds

#

It might be better to just recode this from scratch 💀

devout path
#

the syscall?

hazy saddle
#

The syscall stuff

#

I think the GDT part is fine?

devout path
#

y e s

hazy saddle
#

That can be cherry picked for a new attempt

#

And the MSRs

devout path
#

can u send me a zip file of a clean without the syscal version

#

or is it in the git

hazy saddle
#

Uhhhhhh

#

Ermmmmm

devout path
#

hub

hazy saddle
#

Uhhhhhhhhhh

devout path
#

oh nvm

#

well iz fine

hazy saddle
#

I never made a commit

devout path
#

XD

#

weeel

hazy saddle
#

I was gonna but

devout path
#

this is why u make commits XD

hazy saddle
#

I thought

#

Oh yeah easy 20 minute adventure

#

Just set some MSRs

devout path
#

xd yes

hazy saddle
#

@devout path this would mean you could probably fully PR this commit tbh

#

Because it’s a lot more of a minimal change your your doing most of it heh

devout path
#

yeeeeeeeeeeeeeeeeeeaaaaaaaaaaaaaaaaaaaaaaaaahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

#

i m eaaan ;-;

hazy saddle
#

What

devout path
#

yeah why not XD

devout path
hazy saddle
#

Get your name in the open source

devout path
#

hmm?

hazy saddle
#

Or somthing I dunno heh

#

Just like your GitHub account would be linked to the commits

#

But yeah wtf is up with these bugs

devout path
#

i have 0 clue

hazy saddle
#

Like where the fuck in the code is causing it

devout path
#

hooooooonestly

hazy saddle
#

Maybe use a per thread global instead of gs @devout path and refer to it from assembly and for many cores make it an array

devout path
#

hmmm yes yes

hazy saddle
#

And then index by current core ID from reading the MSR that has that

#

Wait wait

#

@devout path what if you use the kernel base gs

devout path
#

hmmmmmmmm

hazy saddle
#

And change the write to the KBASEGS MSR

devout path
#

could work

hazy saddle
#

And then in the start of the kernel run a swapgs

#

@viral bison mentioned UBASEGS caused issues

devout path
#

hmm ye syes

hazy saddle
#

Plus the kernel using the KERNEL base gs would make more sense

devout path
#

yeah true

hazy saddle
#

@devout path is it working?

#

Or should I test that

devout path
#

wdym

#

can u test it for me pls

#

am not doin it rn i have life stuff xd

hazy saddle
#

its not super paniing

devout path
#

all roads lead to albuquerqe

devout path
hazy saddle
#

if i rever it

#

its still 0s

#

??

#

wait

devout path
#

hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhuh

hazy saddle
#

no yeah

devout path
#

errrr

hazy saddle
#

btw whys 0x06 on the IP
CR2=0x0000000000000006

#

of all things

#

f
mov [gs:32], rsp
mov rsp, [gs:24]
...
mov [gs:24], rsp
mov rsp, [gs:32]

#

this is correct rigjt

hazy saddle
#

w h a

devout path
#

i have no clue whatsover

hazy saddle
#

is there anyone we know that can help

devout path
#

heh ;-;

#

idk

rancid viper
#

whats up

hazy saddle
#

SYSRET is a companion instruction to the SYSCALL instruction. It returns from an OS system-call handler to user code at privilege level 3. It does so by loading RIP from RCX and loading RFLAGS from R11.1 With a 64-bit operand size, SYSRET remains in 64-bit mode; otherwise, it enters compatibility mode and only the low 32 bits of the registers are loaded.
hm @devout path

hazy saddle
#
SYSCALL invokes an OS system-call handler at privilege level 0. It does so by loading RIP from the IA32_LSTAR MSR (after saving the address of the instruction following SYSCALL into RCX). (The WRMSR instruction ensures that the IA32_LSTAR MSR always contain a canonical address.)

SYSCALL also saves RFLAGS into R11 and then masks RFLAGS using the IA32_FMASK MSR (MSR address C0000084H); specifically, the processor clears in RFLAGS every bit corresponding to a bit that is set in the IA32_FMASK MSR.
#

do we clobber RCX anywhere

#

or R11

devout path
#

wat

#

in the kernel?

hazy saddle
#

yes

devout path
#

i have 0 clue

#

XD

#

i mean

#

isn't that what syscall should do

hazy saddle
#

if i change from sysretq to sysret i fer a diffrent error

devout path
#

wat error

hazy saddle
#

this is sysretq

#

normal sysret

devout path
#

huh

#

isn't sysretq explicit for x64

#

sysretq

hazy saddle
#

idk

devout path
#

h u h ?

hazy saddle
#

no

#

i dont think s o

devout path
#

then y is it different... <

#

i refactored the syscall a bit but

rancid viper
#

sysretq is not valid

#

nasm thinks its a label u fucked up

#

so it outputs nothing

devout path
#

true..

rancid viper
#

u really should run with -Werror

#

o64 sysret

hazy saddle
#

src/kernel/interupts/syscall.asm:55: error: label sysretq' alone on a line without a colon might be in error [-w+error=label-orphan]`

#

h u h

#

n e a t

rancid viper
#

yes

hazy saddle
#

whats these

src/kernel/interupts/interupts.asm:38: error: 32-bit relative section-crossing relocation [-w+error=reloc-rel-dword]
make[1]: *** [GNUmakefile:235: obj-x86_64/src/kernel/interupts/interupts.asm.o] Error 1
make[1]: *** Waiting for unfinished jobs....
src/kernel/interupts/syscall.asm:32: error: 32-bit relative section-crossing relocation [-w+error=reloc-rel-dword]
make[1]: *** [GNUmakefile:235: obj-x86_64/src/kernel/interupts/syscall.asm.o] Error 1
#

call dispatch_interupt

devout path
#

prolly has dsometing to do with that

viral bison
viral bison
hazy saddle
#

fixing the assembly

viral bison
#

what was wrong with it?

hazy saddle
#

aparently i need this

#

because

viral bison
#

why not just call dispatch_int?

hazy saddle
#

then it gives the error

#

nope still errors pain

rancid viper
#

how do you compile your assembly

hazy saddle
#

nasm

rancid viper
#

yes.....

hazy saddle
devout path
#

no?

hazy saddle
#

it errors

#

src/kernel/interupts/syscall.asm:32: error: 32-bit relative section-crossing relocation [-w+error=reloc-rel-dword]

#

and the other way will too
64-bit absolute section-crossing relocation [-w+error=reloc-abs-qword]

rancid viper
#

are you like putting this in some other section

hazy saddle
#

call execute_syscall

#

what section

#

what is a section and where would it be going

rancid viper
#

elf section

hazy saddle
#

default?

rancid viper
#

default should be text

#

which is correct

hazy saddle
#

it works if i ignore errors for interupts but not syscalls

#

but

devout path
#

imma be back in an hour

#

imma just burn stress

hazy saddle
#

Same

viral bison
#

@hazy saddle try to compile your OS with clang

#

assembly too

#

maybe it'll work better by using just 1 compiler for everything

rancid viper
#

in general you need to narrow the issue

#

it really seems you guys are just searching in the dark

viral bison
#

well, we did find that it is somehow jumping to rdi

#

when it's pushed to the stack

#

or a bit later

hazy saddle
viral bison
#

yes, ofc

hazy saddle
#

What flags should I change in the makefile

viral bison
#

sec, i'm finishing to edit the makefile

#

then i'll send it here

rancid viper
#

nasm syntax does happen to be very close to intel syntax so it might work

viral bison
#

yeah i found something that needs fixing for it

rancid viper
#

and why change assemblers

viral bison
#

i tought the syntax was the same

rancid viper
#

its not

hazy saddle
#

It’s diamonds idea

viral bison
#

lemme finish to convert them

rancid viper
#

well ill just put it this way

#

if changing assemblers fixes something

#

there is some deeper issue

#

doesnt seem very productive

hazy saddle
viral bison
#

idk

hazy saddle
#

Instead of whatever the fuck sysretq is

#

Maybe we just ignore the 32bit whatever NASM error garbage is

floral kettle
#

sysretq is what you should use (or in nasm o64 sysret, though sysretq probably works in nasm too idr)

#

because by default sysret is going to return to compatibility mode if you don't do that

hazy saddle
#

h u h

#

sysretq did not work in nasm

#

it thought it was a lebel

floral kettle
#

ah then ig it only supports the o64 sysret variant

hazy saddle
#

how do i fix this aswell?
src/kernel/interupts/interupts.asm:40: error: 32-bit relative section-crossing relocation [-w+error=reloc-rel-dword]

#

so i need another o64 on iretq?

floral kettle
#

probably yeah o64 iret

hazy saddle
#

nope

src/kernel/interupts/syscall.asm:32: error: 32-bit relative section-crossing relocation [-w+error=reloc-rel-dword]
src/kernel/interupts/interupts.asm:40: error: 32-bit relative section-crossing relocation [-w+error=reloc-rel-dword]
#

both on the calls to c functions

#

leme just mute that

#

this is new

#

looks like its executing thr wrong systemcall

#

eg this heh

rancid viper
#

moral of the story is werror

hazy saddle
#

GPF here now @devout path @viral bison

0xffffffff8000c1ea
dispatch_interupt_asm
src/kernel/interupts/interupts.asm:?
viral bison
#

hmmm

rancid viper
#

whats the error code of the gpf

hazy saddle
#
ERROR : 00000000 00000000 00000000 00010000 
viral bison
#

your IDT is so fucked btw

hazy saddle
#

hm?

viral bison
#

i'm fixing all of it

hazy saddle
viral bison
#

the IDT entry is completely wrong

hazy saddle
#

bwuh

rancid viper
#

give me qemu log

hazy saddle
#

leme generate

rancid viper
#

I dont trust ur print

#

that is not a valid error code for a gpf

hazy saddle
#

ooo my stack tarce worked for once here kinda

#

in debug mode it dosnt do tht garbage

rancid viper
#

yeah look at that

#

0x10

hazy saddle
#

whats 0x10?

rancid viper
#

2nd index of the gdt

#

is what that error code means

hazy saddle
#

ah

rancid viper
#

so segment error on index 2 of the gdt

hazy saddle
#

gdt_fill_entry (2, 0x92, 0xC); // 64 Bit Kernel Data | 0x10
hm

rancid viper
#

can you dump the gdt

hazy saddle
#

how

rancid viper
#

whatever is convenient

#

qemu monitor?

hazy saddle
#

i dont know any methods

#

what do i enter there

viral bison
#

also, why were you using 32 bit flags for your IDT?

hazy saddle
#

etc etc

rancid viper
#

tbh this would be much easier if u just used constants for the gdt

#

xd

viral bison
#

0x8E is for 32 bit

#

64 bit is 0xE

#

same for the F

hazy saddle
#

is that not for user callable interupts?

viral bison
#

no

hazy saddle
#

how did it even fucking work then

viral bison
#

DPL is for that

#

or well, selector in your case

rancid viper
viral bison
rancid viper
#

send me a link to their idt coide

viral bison
#

it's in the zip

#

there is no link

#

lol

rancid viper
#

jesus im not doing allat

#

anyway at least I have a struct that looks like this

viral bison
#

yes it is

rancid viper
#

correct value for an interrupt gate here is to set flags to 0x8E

viral bison
#

but how the flags are set was wrong

#

huh?

rancid viper
#

which is one flag

viral bison
#

ah wait

rancid viper
#

flags covers present, dpl, gate type

viral bison
#

i split the DPL that's why

rancid viper
#

bit 7 is present

#

bit 7 of a byte is 0x80

#

0x80 | 0xE = 0x8E

rancid viper
#

I dont use bit fields anywhere

hazy saddle
#

my patchset isnt touching idt

viral bison
#

fuck

hazy saddle
#

And because some how the error code is the only thing that did not break

viral bison
#

IT WORKS

#

well, not really works

#

but at least it doesn't pagefault anymore

hazy saddle
#

What’s the fault now

#

GPF?

viral bison
#

triple fault after it runs a bit

hazy saddle
#

But bad apple runs?

viral bison
#

prob something wrong when executing syscalls

viral bison
viral bison
#

i think it's your printf

devout path
#

i go back

#

then i see this XD

#

wild

hazy saddle
#

Probaly the printf systemcall

hazy saddle
viral bison
devout path
#

wat

#

is it fixed

hazy saddle
#

TF still maybe

viral bison
#

Somewhat

#

It does run a bit tho

#

So it might be some syscall impl

#

Ans it uses clang now

hazy saddle
#

i hate intel syntax

#

the macros are disgusting

#

your zip seems to be bad

viral bison
#

Hmm

#

Lemme try tar

hazy saddle
#

you also forgot all the dot files

#

like .git and .gitignore

viral bison
#

I told it to include everything

#

F

rancid viper
#

zip -r dir dir

#

: )

hazy saddle
#

what else did you change besides the IDT btw

viral bison
#

Most of the asm files

rancid viper
#

git diff HEAD~1 HEAD

hazy saddle
#

@viral bison gimme a patch file to apply to main

devout path
#

ima be back tmr i forgor i have a shit ton of things todo

#

if this not fixed till tmr im gonna try

hazy saddle
viral bison
#

yeah well

#

that might be bc of the archive you gave me

hazy saddle
#

huh

#

can you should me the diffs of the file in your ide

viral bison
#

after i unzipped it, it showed all the files edited

#

patch too

#

the edits seems to be in the file modes

#

oh well

rancid viper
#

WSL?

viral bison
#

no

#

i'm on arch

rancid viper
#

evalyn? wsl?

devout path
#

who uses wsl nowadays

rancid viper
#

: )

hazy saddle
rancid viper
#

well

#

someones got fucked up shit

#

lol

hazy saddle
#

I’ve been awake a few hours

#

And il already sleepy as fuck

devout path
viral bison
#

It should work anyway

devout path
#

take nap it 'll go away

hazy saddle
#

Okay okay

#

New plan

#

Trash this code

#

And get a minimum working code

viral bison
#

And use the one i sent?

hazy saddle
#

Il be using bits from all of these

#

What was wrong with my idt

#

I want to keep NASM

viral bison
#

Nasm is pain

hazy saddle
#

The syntax is better for my mush brain

devout path
#

wait why idt change

viral bison
#

I used macros to auto gen all the 256 interrupts

#

And then get the address of the handlers from an array

#

Set via asm

#
  • some exception flags were wrong
hazy saddle
#

I think the other way is fine and more explicit imo?

hazy saddle
#

I mean take those fixes

viral bison
#

It's worse the way it was before

rancid viper
#

I'd help but I am currently working so 🙂

hazy saddle
#

I’m gonna take a break

#

And play a game maybe

#

Maybe eat food

#

I haven’t eaten

#

In today

devout path
#

tbh

#

i suggest everyone to take a break from this os for a day XD

#

this made my brain mush more than it was

rancid viper
#

you should keep an up-to-date dev branch

#

because these patches and zip files makes it just unecessarily difficult to help

devout path
hazy saddle
devout path
#

u can commit everytime u do a minor change

hazy saddle
#

What do I name it

devout path
#

so i can develop on top of that with the block driver that im making

rancid viper
#

dev

devout path
#

make it weedbranch

hazy saddle
rancid viper
#

or something

#

lmao

devout path
#

weeddev

#

cuz it'll be high

#

yes

#

most of the time

rancid viper
#

then you can just cherry-pick and rebase everything u want to main

#

like I can understand wanting to keep a clean main

#

but this current system aint it

hazy saddle
#

Yeahhhh

#

What if I call it unstable?

rancid viper
#

it is your thing

#

call it what u want 😄

devout path
#

yes

hazy saddle
hazy saddle
#

Il call it dev

devout path
hazy saddle
#

All commits Goto dev

#

And when it’s time for main

#

Il squash and then merge into main

devout path
#

iz it fine if u make me a collaborator

hazy saddle
#

I should

devout path
#

yez

rancid viper
#

prs exist too 🙂

hazy saddle
#

Can I give you perms on the dev branch but not main?

devout path
#

yes

#

ofc

rancid viper
#

on a public thingh

#

yes

#

for private u need to pay

hazy saddle
#

It’s public

rancid viper
#

yep

#

basically u just setup branch protection for mai

#

n

hazy saddle
#

Okay I’m gonna get food and then get a commit with the gdt changes that were good

#

And then get the somewhat not working syscalls in dev

hazy saddle
#

And then get @devout path and @viral bison as collabs on the dev branch

devout path
#

yes

#

pls don't foret to make it always up to date though ;-;

#

so i can alwys check it

hazy saddle
#

I am making the executive decision to stick with NASM

#

As it’s what I’m used to and I prefer the syntax

hazy saddle
#

And then once we get a feature working it gets squashed to main

devout path
#

yes

#

good devops

#

xd

#

i ain't a devops engineer but that sounds great

hazy saddle
#

Also you want to get added to my personal dev server? so I can setup a bot with git notifications and for other generic chatting that may not be good for here lmao

#

Possibly helpful hmmCat

devout path
#

yes yes

hazy saddle
#

So new features go there instead of main

#

Just incase

#

Then things go dev > unstable > main

devout path
hazy saddle
#

I think that milestone should be core utils + shell + nano + doom and ext2 and sata

devout path
#

yes yes

#

@viral bison

#

would u like to be a part of the

#

dev server

viral bison
#

ok then

#

@hazy saddle

hazy saddle
#

dm me if you want the inv

#

its for dev notis and non evalynos chat because yall friends :3

hazy saddle
#

new proper dev branch for changes that may ior may not be buggy

rancid viper
#

the other option (which you cant do atm) is to fork and upstream

#

but that might be excessive for a personal project

hazy saddle
#

@rancid viper progress and im about to push to dev

#

a few syscalls can be ran before death

#

and they are ones i expect

#

it is that invalid GPF error code

#

leme make a quick qemu log file

rancid viper
#

something is wrong w ur error print

hazy saddle
#
    if (frame != NULL) {
        printf("ERROR : " BYTE_TO_BINARY_PATTERN " " BYTE_TO_BINARY_PATTERN
        " " BYTE_TO_BINARY_PATTERN " " BYTE_TO_BINARY_PATTERN " \n",
        BYTE_TO_BINARY(frame->error >> 24), BYTE_TO_BINARY(frame->error > 16),
               BYTE_TO_BINARY(frame->error >> 8), BYTE_TO_BINARY(frame->error));
    }
rancid viper
#

yeah error is still 0x10

hazy saddle
#

but some systemcalls do get to be ran

rancid viper
#

oh wtf it's binary

hazy saddle
#

yes

rancid viper
#

sadist

#

either way

#

error code still points at a segment error on gdt index 2

hazy saddle
#

What happens if limit is 0 or max Fs

rancid viper
#

limit is ignored on x86-64

hazy saddle
#

gdt_fill_entry (2, 0x92, 0xC); // 64 Bit Kernel Data | 0x10

rancid viper
#

why don't u make them constants

hazy saddle
#

i dunno how

rancid viper
#

I'm on my phone atm and can't really investigate what that function does

#

xd

hazy saddle
rancid viper
hazy saddle
#

it does this

rancid viper
#

wait ur flags are weird

hazy saddle
#

huh

rancid viper
#

0xC

#

bits 2, 3

hazy saddle
#

yes

rancid viper
#

so granularity

#

ok

hazy saddle
#

i took the flags and accsess values from here

rancid viper
#

uh bit 2 I don't think should be set

#

hm

#

maybe I'm missing something

floral kettle
#

bit 2 of the flags for data segment should be set, its the 16-bit vs 32-bit data bit

#

and bit 2 of the flags for 64-bit code segment should be cleared (and instead bit 1 set)

hazy saddle
#

this is a 64bit data segment

floral kettle
#

there is no such thing as a 64-bit data segment, it has the same format as a 32-bit data segment

hazy saddle
#

ah

#

so this is correct then?

rancid viper
#

afaik bit 0, 1, 2 should be clear for a 64bit data segment?

#

oh I misread ur thing

#

lol

floral kettle
#

lol

rancid viper
#

Damn I have flags set to zero for my data segments

#

idk

floral kettle
#

idk if it matters in 64-bit tbh, it might not

hazy saddle
#

what bits should 0x10 have on flags

rancid viper
rancid viper
#

qwinci corrected me

hazy saddle
#

ah

#

then whats up with the GPF

rancid viper
#

well start by dumping the instructions where it happened so we know at least what it was trying to do

hazy saddle
#

i dont think this is the right IP?

#

the IP lands somwhere here

#

wait no

#

its just a random match

#
 evalyn@EvalynPC  ~/Documents/Programming/C/evalynOS   master ±✚  addr2line -fai -e  kernel.elf 0xffffffff8000c1ea
0xffffffff8000c1ea
dispatch_interupt_asm
src/kernel/interupts/interupts.asm:?
#

but yeah the IP seems widly off

rancid viper
#

modify this or something

#

and dump like a couple bytes before the rip

hazy saddle
#

pushed to dev

#

here we go

rancid viper
#

ah

#

well can u dump the stack at the time of exception

#

most likely something is wrong with the iret frame ig

hazy saddle
#

Is there a good way to set a breakpoint there but only have it trigger when it’s about to do the GPF?

rancid viper
#

u can just dump using qemu monitor after the fact

#

I don't think it consumes the frame if u fault

#

thought not 100% sure on that one

hazy saddle
#

@rancid viper is this what you needed

rancid viper
#

I'll look later

#

still at work need to finish some shit

hazy saddle
rancid viper
#

alright finally

#

9pm

#

got off work

hazy saddle
#

nice!

#

i got CPUID working in the meantime

#

And if on physical hardware the frame buffer will get WC enabled to speed it up

hazy saddle
#

hmmmmmmmmmmmmmmmm

#

huh wtf

#

between the printf and the switch case

#

the stack is fucked

#

its either nanoprintf or flantern maybe?

hazy saddle
#

uhhhhhh

#

i get a page fault if i single step

#

?????

hazy saddle
hazy saddle
#

okay okay

#

ive made some more progress

#

syscalls can kinda work

#

but they then crash horridly

#

and the original error before it fully died from seriel is as here

FREE WILL IS A FLAW
General Protection Fault
General Registers:
RAX=0x0000000000000000 RBX=0x000000000000000b
RCX=0x00000000a0000000 RDX=0x000000000000002b
RSI=0x0000000000000001 RDI=0x0000000000000000
RBP=0x000000000000006c RSP=0xffff810000020998
R8 =0x00000000004ac200 R9 =0x0000000000000008
R10=0x0000000000000029 R11=0x000000000000002e
R12=0x0000000000000024 R13=0x00000000004ac210
R14=0x00000000a0035c00 R15=0x000000000000d200
Interrupt Frame:
IP=0xffffffff8000c4aa SP=0xffff810000020998
SS=0x0000000000000010 CS=0x0000000000000008
FLAGS : 00000000 00000001 00000000 10000010 
Control Registers:
CR0: 10000000 00000001 00000000 00010001 
CR4: 00000000 00000000 00000010 00100000 
CR8: 00000000 00000000 00000000 00000000 
CR2=0x0000000000000000 CR3=0x0000000001d94000
Misc:
ERROR : 00000000 00000001 00000000 00100000 
RFLAGS: 00000000 00000001 00000000 10000010 
GDTR Base=0xffffffff80016340 GDTR Limit=0x0000003f
IDTR Base=0xffffffff800193a0 IDTR Limit=0x00000fff
LDT=00000000 TR=00000030
#

the STAR MSR was being set wrong

#

which did some funky things

#

because i forgot one < yaaar

#

im unsure on SFMASK

#

i tried to look at other implementations for a proper mask and i tried some and they did not work. only 0 worked whoch others tell me isnt correct

#

i also properly told the thing it wold have RCX and R11 clobberd heh

#

aswell this made things a lil more stable

#

i may push to dev in a bit and keep working on this

#

but i am a lil confused

hazy saddle
#

but the user space app manages to survive a few seconds before death

hazy saddle
#

Oops. Undoing that change

hazy saddle
#

fault seems to be coming from here

/home/evalyn/Documents/Programming/C/evalynOS/src/kernel/interupts//src/kernel/interupts/interupts.asm:57

which is the iretq here

    pop rcx
    pop rbx
    pop rax

    add rsp, 16
    iretq
hazy saddle
viral bison
#

yeah i forgot you are using normal syscalls rn

hazy saddle
#

Something is fucking up shit when it system calls and then comes back to interupt

#

Also that’s the same IP as when I had the mask be 0

#

So that seems to delay the inevitable

viral bison
#

maybe a race condition?

hazy saddle
#

maybe?

#

ive tried to add sti/cli in both handlers but no luck

viral bison
#

i think i'm fighting with something similar in my scheduler

#

lol

hazy saddle
#

I wasn’t able to get your scheduler trick to work

#

But this way shouldddd be fine too

#

It’s just usureaboutthat

#

Acting up

viral bison
hazy saddle
#

The int handler calls the PIT code which calls the secedular which then calls the assembly… which then never pops the things off the stack right?

#

Meaning stack overflow

#

But why did this never overflow before like this?

#

Even with running the kernel for hours?

viral bison
#

So i'm making a dedicated handler

hazy saddle
#

is there a way i can track the RSP to check if its doing that to me

#

maybe it could explain musterious stack coruption?

#

wana go over again with me how it should be domne?
its an assembly ISR that on trigger passes the current RSP to a C function and then switch to the RSP returned by said function @viral bison?

hazy saddle
#

What’s the GDB command to make or print that every step?

viral bison
#

get gef

hazy saddle
viral bison
#

and the ni to single step instructions (in asm)

#

or n for c code

#

s to step in

#

and fin to finish the current function

hazy saddle
#

And I assume I have a breakpoint on the syscall handler

viral bison
#

if you use kvm you have to use hb

#

and you can have max 10 hbs

hazy saddle
#

I use TCG when debugging

#

What’s an HB?

viral bison
#

hardware break

hazy saddle
#

Hardware breakpoint

#

Ah

viral bison
#

it should

#

but remember that if you get the rip inside the int handler, you'll get the code inside the int handler

#

but if you have a dedicated handler, you get the code from where that int was called

hazy saddle
#

Where would I be using the RIP here?

viral bison
#

on the ret / iret

hazy saddle
#

Would this new all assembly one still need to push and pop every register?

viral bison
#

not every

#

you have 11 regs in total

hazy saddle
#

Just the normal ones I already do

viral bison
#

5 from iret

#

and 6 that you do currently

hazy saddle
#

somthing like this @viral bison ?

pit_isr_schedule:
    pushfq
    push rbx
    push rbp
    push r12
    push r13
    push r14
    push r15

    mov rdi, rsp
    call the_c_function
    mov rsp, rax

    pop r15
    pop r14
    pop r13
    pop r12
    pop rbp
    pop rbx
    popfq

    ret
viral bison
#

yes

#

tho prob pushfq is not needed

hazy saddle
#

yeah but removing it before borked shit

viral bison
#

also, you prob want a load cr6 before mov rsp, rsi

#

and you also don't have rsi btw

hazy saddle
#

cr3? and would the C function do that

viral bison
#

just do mov cr3, regs

hazy saddle
#

but i have a C function that handles that with some extra stuff. and cant i only return one thing?

#

and the return is in rax right

#

so i changed that

viral bison
#

it should be done in asm if you don't want a pagefault

viral bison
hazy saddle
#

so how do i return 2 values properly?

viral bison
#

return an uint128

hazy saddle
viral bison
#

lower 64 bits are on rax

#

top are on rdx

hazy saddle
#

@viral bison i dont have a uint128

viral bison
#

make it

hazy saddle
#

how

viral bison
hazy saddle
#

wut

viral bison
#

look at how i did it

hazy saddle
#

i am?

#

im confused

#

how does that even work

viral bison
#

it's a compiler macro

hazy saddle
#

yes

#

but where is the 128 bit integer primative coming from

viral bison
#

macro

#

it's builtin in the compiler

#

dw about it

hazy saddle
#

i dont have that

#

where

#

of course

#

autocomplete wont show it

#

but it works

#

fml

#

@viral bison so like this
return ((__uint128_t)current_thread->pagemap->top_level << 64) | current_thread->krsp;

viral bison
#

yes

hazy saddle
#

@viral bison

#
__uint128_t schedule(uint64_t old_krsp) {
    pitInteruptsTriggered++;
    if (shouldSchedule) {
        struct thread *previous_thread = threads->thread;
        threads = threads->next_thread;
        struct thread *current_thread = threads->thread;

        vmm_switch_to(current_thread->pagemap);

        tss.rsp0 = (uint64_t)current_thread->stack_top;
        wrmsr(UGSBAS, (uint64_t)current_thread);

        previous_thread->krsp = old_krsp;
        return ((__uint128_t)current_thread->pagemap->top_level << 64) | current_thread->krsp;
    } else {
        return ((__uint128_t)kernel_pagemap->top_level << 64) | old_krsp;
    }
}
#
global isr0x20
extern schedule
isr0x20:
    pushfq
    push rbx
    push rbp
    push r12
    push r13
    push r14
    push r15

    mov rdi, rsp
    call schedule
    mov rsp, rax
    mov cr3, rdx

    pop r15
    pop r14
    pop r13
    pop r12
    pop rbp
    pop rbx

    ; send EOI
    push rax
    mov al, 0x20
    out 0x20, al
    pop rax

    iretq
#

where is it going to 0x0 yaaar

viral bison
#

how are you steting the initial stack?

hazy saddle
#

true leme check

#
    *--stack = (uint64_t)task_quit;
    *--stack = (uint64_t)entry_point;
    *--stack = 0x202;

    *--stack = 0;
    *--stack = 0;
    *--stack = 0;
    *--stack = 0;
    *--stack = 0;
    *--stack = 0;
viral bison
#

yeah well

#

you are missing quite a few registers

hazy saddle
#

wait wha

viral bison
#

first of all

#

you forgot a popfq

hazy saddle
#

fuk

viral bison
#

2nd, iretq uses 5 registers

#

rsi = rip

#

[rdi] = stack pointer

hazy saddle
#

so do i want ret?

viral bison
#

no

#

just add 4 regs to your stack setting

#

after the rip

hazy saddle
#

so this and this

#

wait after rip

#

so

#

nope

viral bison
#

BRUH

hazy saddle
#

what did i do 😭

viral bison
#

look at how i set them

hazy saddle
#

i thought i did yaaar

viral bison
#

and i told you to add them before entry point

hazy saddle
viral bison
#

also, flags are not needed (pushfq and popfq)

#

bc the interrupt does it all for you

#

and iret restores the flags

hazy saddle
#

so this pwease

viral bison
#

in my case the flags are 0x292

viral bison
hazy saddle
#

dont i do this in assembly?

viral bison
#

the stack you are setting is all 0

#

lol

hazy saddle
#

yes?

viral bison
#

yeah, and that values are meant to be in the stack

#

lol

hazy saddle
#

goddamnit what do i need to put there yaaar

viral bison
#

*--stack=0x10;
*--stack=rsp;
*--stack=0x292 (or your rflags);
*--stack=0x08;
*--stack=rip;

hazy saddle
#

my brain isnt working

#

thank you

#

wait what rsp do i put there?

viral bison
#

the thread one

#

kernel

hazy saddle
#

what

#

thats in C right?????

viral bison
#

the kernel thread stack

hazy saddle
#

;-;

viral bison
#

i think you save the thread rsp, no?

hazy saddle
#

fuk

#

im dum

#

whyyyy

#

wait

#

i need to offset that

#

right

#

dosnt help yaaar

#

10 11 or 12 breaks

viral bison
#

ehm

#

don't shift maybe?

#

just put stack top

#

the values will be popped anyway when iret reaches that rsp

hazy saddle
#

Even without shifting

#

It breaks

hazy saddle
viral bison
#

single step then

#

and check values

hazy saddle
#

To be clear

#

This crashes before the schedules even runs

viral bison
#

lol what

#

then it's not an iret problem

hazy saddle
#

Yes

viral bison
#

find where it crashes then

hazy saddle
#

return ((__uint128_t)kernel_pagemap->top_level << 64) | old_krsp;

#

shit

#

thats not valid

viral bison
#

huh?

hazy saddle
#

the PIT is setup before the vmm

viral bison
#

loooool

#

just do sti when you are done initializing

hazy saddle
#

now it only GPFs

#

wtf??????

#

im done

#

wtf is this

viral bison
#

?

hazy saddle
#

i changed the code

#

no change

hazy saddle
#

@viral bison update this will not cause a crash

#

but it locks up all interupts??

#
global isr0x20
extern schedule
extern shouldSchedule
extern pitInteruptsTriggered
isr0x20:
    add dword [rel pitInteruptsTriggered], 1
    push rax
    mov rax, [rel shouldSchedule]
    cmp rax, 1
    pop rax
    je do_schedule
    jne dont_schedule

    do_schedule:
    push rbx
    push rbp
    push r12
    push r13
    push r14
    push r15

    mov rdi, rsp
    call schedule
    mov rsp, rax
    mov cr3, rdx

    pop r15
    pop r14
    pop r13
    pop r12
    pop rbp
    pop rbx

    ; send EOI
    push rax
    mov al, 0x20
    out 0x20, al
    pop rax

    push 0x10
    push [rdi]
    push 0x292
    push 0x08
    push rsi

    dont_schedule:

    sti

    iretq
#

even just this will?????

#
isr0x20:
    add dword [rel pitInteruptsTriggered], 1

    push rax
    mov al, 0x20
    out 0x20, al
    pop rax
    sti
    iretq

hazy saddle
#

yeah @viral bison im never gonna get your way to work.
even making my normal PIT isr in assemblu without the new functon is still fucked

hazy saddle
viral bison
hazy saddle
#

so from here what should i be doing?
pop that into a register?

viral bison
#

i told you to not push flags

hazy saddle
#

FUCK

viral bison
#

it won't do anything really

hazy saddle
#

i completly refid the section

#

how did that even stay there 😭

viral bison
#

it's just an useless push / pop

hazy saddle
#

ok ok

#

but what do I need to do

viral bison
#

these here are completely wrong

hazy saddle
#

why tf is it tripple faulting

#

is this also fucked

viral bison
viral bison
#

but you are pushing wrong values

hazy saddle
#

then why did ytou tell me to put thoes there before

viral bison
#

i push them in my stack init...

#

i told you

viral bison
hazy saddle
viral bison
#

f

hazy saddle
#

whats the proper values?

viral bison
#

you have to remove those 5 pushes in the isr

hazy saddle
#

i did

viral bison
#

k, good

hazy saddle
#

it dosnt crash but it locks up

#

do i need a sti?

#

no

#

it dosnt fix it

#

it seems to not be scheduling @viral bison??
but if i add a second thread it kinda goes but it page faults

viral bison
#

bruh

hazy saddle
#

and its only because its two of the same

#

otherwise still halts?

#

im sorry

#

what did i fuck up this time im so sorry

#

@viral bison somehow somewhere interupts get disabled goddamnit

hazy saddle
#

yes

viral bison
#

oof

hazy saddle
#

even this wont fix it

#

whyyyyy

#

the EOI is right here too

#

I genuinely don’t know what the fuck to do anymore

#

I’m fucking cursed

#

@viral bison is this correct too or am i being dumb??

viral bison
#

should be

hazy saddle
#

so any ideas?

floral kettle
#

fwiw I wouldn't tie scheduling to interrupts, it just ends up being messy

#

if you are doing the same thing as what diamondmaster did that is

viral bison
floral kettle
#

you just call sched() in your timer handler

hazy saddle
#

i mean thats what @viral bison said for me to do
i used to have the PIT ISR call schedule()

#

but aparently that caused issues

viral bison
hazy saddle
#

acording to diamond

floral kettle
#

yes?

viral bison
#

bc the lapic sends interrupts

viral bison
#

ye

floral kettle
#

what I mean is that imo its cleaner if its a normal function you can just call anywhere to switch between threads

#

and then resume at that exact same point later on

viral bison
#

oh, i have a function that calls the interrupt, lol

dense cargo
viral bison
#

i had problems with structs

hazy saddle
#

utint128 splits the two halfs into registers

dense cargo
floral kettle
#
// void sched_switch_thread(uintptr_t* old_sp_loc, uintptr_t new_sp)
sched_switch_thread:
push rbx
push rbp
push r12
push r13
push r14
push r15

mov [rdi], rsp
mov rsp, rsi

pop r15
pop r14
pop r13
pop r12
pop rbp
pop rbx
ret
viral bison
#

tho if this is called from an isr, it will then go back and finish that isr, potentially messing things up

floral kettle
#
void sched() {
    // choose next_thread, update msrs and load page map etc
    // switch to there
    sched_switch_thread(&current_thread->sp, new_thread->sp);
}
hazy saddle
#

yeah i had this before
removing pushfq broke things though

thread_switch:
    pushfq
    push rbx
    push rbp
    push r12
    push r13
    push r14
    push r15

    mov [rdi], rsp
    mov rsp, rsi

    pop r15
    pop r14
    pop r13
    pop r12
    pop rbp
    pop rbx
    popfq

    ret
floral kettle
viral bison
#

in c++ it complains

#

the struct i mean

dense cargo
floral kettle
#

it was only because you had the initializers

viral bison
#

oh

hazy saddle
floral kettle
#

idk, or you could try fixing it somehow

viral bison
#

i'm trying to fix mine too

dense cargo
viral bison
#

somehow the stack gets fucked up if i don't put a print on the function XD

dense cargo
#

but if the problem was caused just by initializers then it would be a good idea to go back to that implementation

hazy saddle
#

and that worked

#

but syscall is still fucked

#

but ive had some minor fixes and progress

floral kettle
#

is it related to the sched stuff though or is it unrelated

dense cargo
#

it's a common mistake

hazy saddle
#

and i dont think so

dense cargo
#

so you're using a thread kernel stack

hazy saddle
#

yes

#

is that bad?

dense cargo
#

like stacks being overwritten when a syscall handler yields and another thread requests a syscall

hazy saddle
#

yes

#

so what is going on with it yaaar

#

pretty sure it is setup right

#

and my gdt is as such

dense cargo
#

32bit user code?

#

why is that?

hazy saddle
#

its what @viral bison told me i needed yaaar

viral bison
#

it could be skipped

#

but i do recommend it

dense cargo
#

compability mode?

viral bison
#

ye

hazy saddle
#

i dont do compat mode but aparently its needed to be that format for STAR?

viral bison
#

you could skip it

#

and change that value to the one before the user data 64

#

tho you have to then be careful to not call syscall from 32 bit mode

hazy saddle
dense cargo
viral bison
#

i copied it from someone else

#

that had syscalls working

hazy saddle
#

i copied it from diamond

dense cargo
#

it needs to be coherent with gdt segments

hazy saddle
#

documentation on this is so ass for syscall/sysret

hazy saddle
dense cargo
#

which should come 8 bytes after the 64 bit user data segment

#

(iirc)

hazy saddle
#

then why do some syscalls manage to work before failing i womder

floral kettle
#

the value at star 63:48 should point to the user code32 gdt entry if you have that (and your gdt is of the form user code32, user data, user code64)

dense cargo
#

isn't SS = CS - 8

floral kettle
#

no its cs + 8

#

actually wait no

dense cargo
floral kettle
#

yeah its cs - 8 but star 63:48 doesn't point to cs64

#

if you write 0x18 to star then user cs is at 0x18 + 16 (0x28) and user ss will be 0x18 + 8 (0x20)

#

but anyway it should be correct yeah

hazy saddle
#

So then what else is causing issues?

floral kettle
#

I can try to take a look at it if I can get it triggered again lol

hazy saddle
#

I’m gonna put that all together into a proper commit and push to dev and remove this pit scheduler nonsense

hazy saddle
floral kettle
#

some random page fault when running the badapple cmd a bunch of times, is this different from that now?

hazy saddle
#

If too many system calls run it faults

hazy saddle
#

And I can spawn it as many as I want

#

That’s on main branch

#

But the dev branch is trying to get syscall to work but it’s broken

#

I tried adding more fixes and had some progress

#

But did not fully work and then I spent all day trying to get @viral bison s idea to work

gentle quest
viral bison
#

and later got rid of them

gentle quest
#

Oh

viral bison
#

and never removed extern "C"

hazy saddle
hazy saddle
#

okay well they 100% work once or twice

#

but somthing still gets messed up