if its in C
#Nyaux
surreal path
finite summit
probably
surreal path
lib alloc?
finite summit
allocator library (in C) made to be easily portable
surreal path
allocator library (in C) made to be easily portable
cant import it cause my pmm doesnt alloc physically continigous pages and my vmm relys on the slab
cinder plinth
i use liballoc and use my vmm to allocate virtually contiguous pages to map physically separate pages
daring juniper
Yuck! Virtual Memory.
finite summit
booo
surreal path
i use liballoc and use my vmm to allocate virtually contiguous pages to map phys...
my vmm relys on the slab
allocator
☠️
surreal path
you need a virtual memory allocator
yea and that relys on the slab to make the heckin
surreal path
vmm region struct
surreal path
sorry i have school rn
which is why
i didnt do anything yet
when i come back from school ill keep researching about slab allocators so i can implment one that DOESNT fault
ionic jetty
Is this turning into obos thread 
?
surreal path
Is this turning into obos thread <:KEKW:913708372329644042> ?
maybe 😭
surreal path
i just fell asleep watching a lecture about slabs
and slept for
3 hours
nah thats crazy
wide nexus
give me a short explanation about slabs
surreal path
give me a short explanation about slabs
a slab allocator works like this
you have a cache that has a pointer to the current slab being used, a list of slabs that are full and list of slabs that arent full but arent empty either.
when we run out of memory on a slab we switch to ones that are in the partial list, if there arent any then we allocate a new one to switch to.
in linux the kmalloc function is implmented by having caches from the pow2
surreal path
yea
i guess the next thing to do
is to start implmenting this now
i think i understand it to a point
i can implment it
shut laurel
I think linux doesn’t only have pow2 caches
iirc the generic kmalloc ones are pow2
ionic jetty
I don’t know about the others but slub defines non pow2 ones too, and this becomes apparent when cat-ing /proc/slabinfo
Theres like 192 byte generic ones
(For specific slabs like dentries there are more specific sizes too)
shut laurel
yup, couldnt check
haughty kite
not particularly
haughty kite
u tell me how to make it kawaii then
get to full userspace, implement a gui and plaster a random anime wallpaper on it?
surreal path
get to full userspace, implement a gui and plaster a random anime wallpaper on i...
hmm
kind root
yeah memeing the kernel log, or using trash variable names is just you making fun of yourself at your own expense
cinder plinth
isnt that so kawaii
reminds me of my first kernel like 4 years ago
I had the same type of logs but on vga
surreal path
yeah memeing the kernel log, or using trash variable names is just you making fu...
i make fun of myself all the time
!!!
surreal path
I had the same type of logs but on vga
lmao
kind root
idk man this is just sad
surreal path
idk man this is just sad
fine ill revert it
kind root
you should respect your work more
surreal path
look i reverted it u happy?
kind root
yes im very happy because your kernel now uses ok instead of whatever shit it was before
surreal path
yes im very happy because your kernel now uses ok instead of whatever shit it wa...
yes great
ok im gonna work on slab
kind root
my work is shit
as long as you treat it like shit it will stay that way
surreal path
as long as you treat it like shit it will stay that way
fine i wont
i will treat it like amazing
kind root
no just treat it as a reflection of yourself, and actually put in effort to make it look good
then it will be good
surreal path
no just treat it as a reflection of yourself, and actually put in effort to make...
okay
anyways i feel like store size in header as well
idk
im just thinking of like
how itll work when freeing and allocing
i think this looks correct
header is 16 bytes
surreal path
i think this looks correct
do i even need to size + sizeof(struct pmm_node)
why am i even doing that
yea i dont think i need to do that
that just wastes space
lmao
we can fit 510 objects in the page
cool
i think this is valid?
okay
i feel so scared typing each line of code
i feel like im gonna instant fuck up the page or something
lmao
okay
i think this is good
kind root
Looks good
surreal path
Looks good
think this looks good
kind root
No idea
kind root
Add an if addr == 0 return
kind root
Lmao
surreal path
I doubt it will survive uACPI init
kind root
Because that would mean you're better than oberrow
surreal path
Because that would mean you're better than oberrow
dangling namespace node?
huh
then it page faults
in nano printf
kind root
Yeah im sorry it didn't survive
surreal path
Yeah im sorry it didn't survive <:KEKW:913708372329644042>
TELL ME WHAT DANGLING NAMESPACE NODE MEANS
kind root
Its unrelated
cinder plinth
why so many memory allocator skill issues recently
kind root
The memory is corrupted
cinder plinth
literally just use liballoc if u cant write your own
surreal path
literally just use liballoc if u cant write your own
no 😠
surreal path
The memory is corrupted
corrupted?
kind root
Yes
cinder plinth
TELL ME WHAT DANGLING NAMESPACE NODE MEANS
it means the namespace node points to nowhere
kind root
Either you allocated more, or allocated less, or returned the same block twice, or freed it early
surreal path
Either you allocated more, or allocated less, or returned the same block twice, ...
lemme look
oh cause it tries to allocate 2
kind root
Also enable debug uACPI log for better tracing
surreal path
Also enable debug uACPI log for better tracing
how
kind root
In the init replace trace with debug
surreal path
kind root
I would also recommend printfs to trace what memory you're returning
surreal path
I would also recommend printfs to trace what memory you're returning
i dont fkn know whats wrong 
everything looks right
kind root
The oberrow curse is upon you now
surreal path
surreal path
Either you allocated more, or allocated less, or returned the same block twice, ...
im trying to think
I GIVE IT CORRECT MEMORY WHY IS IT FKN DANGLING
😠
kind root
I dont see u logging any addresses
surreal path
ok wait
THEY LOOK VALID
like wtf
and it page faults in nano printf???? like sorry wtf is going on
kind root
Yeah that probably means you're trashing the memory from somewhere
surreal path
Yeah that probably means you're trashing the memory from somewhere
trashing?
kind root
Overwriting
surreal path
when i free i dont memzero
is that a problem
should i memzero the memory before i like
yk
i also dont memzero
when i give the block
@kind root
do i need to memzero?
kind root
Yes
kind root
void *I_have_no_self_respect
kind root
Lol
surreal path
I MEMZERO'D AND I GOT CLOSER
surreal path
probs cause the cache i gave was 051i20958190258190285019285125
so bro requested 528
wtf is going on
kind root
Round up to next power of two?
surreal path
kind root
Yup
surreal path
Yup
got closer and now it page faults in h->freelist = him->next;
loool
ummm
why is the memory address 30000000
why tf
I DONT FUCKING KNOW
WHY THE ADDRESS IS 30000000
why is it pointing
to 3000000
why
fuck me
why
NO ONE IS OVERWRITING THE HEADER
ITS CORRECT
SO WHY IS IT GETTING tHIS STUPID NUMBER
WHY IN THE WHY
void init_cache(struct cache *cache, size_t size)
{
char shit[64] = "";
cache->size = size;
void *page = pmm_alloc_singlep();
struct Header *h = page + hhdm_request.response->offset;
h->size = size;
cache->slabs = (uint64_t)h;
size_t obj_amount = (4096 - sizeof(struct Header)) / (size);
write_color(ctx, "Slab: Creating Cache of Object Count: ", 0);
write(ctx, itoa(shit, obj_amount));
write(ctx, " and Size: ");
write(ctx, itoa(shit, size));
write(ctx, "\n");
struct pmm_node *start = (uint64_t)h + sizeof(struct Header);
h->freelist = start;
struct pmm_node *prev = start;
for (int i = 1; i < obj_amount; i++)
{
struct pmm_node *new = (uint64_t)start + (i * size);
prev->next = new;
prev = new;
}
write_color(ctx, "Slab: Cache Created!\n", 0);
}
struct Header *make_slab(size_t size)
{
void *page = pmm_alloc_singlep();
struct Header *h = page + hhdm_request.response->offset;
h->size = size;
size_t obj_amount = (4096 - sizeof(struct Header)) / (size);
struct pmm_node *start = (uint64_t)h + sizeof(struct Header);
h->freelist = start;
struct pmm_node *prev = start;
for (int i = 1; i < obj_amount; i++)
{
struct pmm_node *new = (uint64_t)start + (i * size);
prev->next = new;
prev = new;
}
return h;
}
like i create the caches correctly
i allocate and free everything correctly
so why is bro pointing to address 3000000
its not from the free function thats causing this
triple checked
not from the making of a new slab either
gotcha
i got u now
interesting
oh wait
itoah
not itoa
struct Header *make_slab(size_t size)
{
char shit[64] = "";
void *page = pmm_alloc_singlep();
struct Header *h = page + hhdm_request.response->offset;
h->size = size;
size_t obj_amount = (4096 - sizeof(struct Header)) / (size);
struct pmm_node *start = (uint64_t)h + sizeof(struct Header);
h->freelist = start;
struct pmm_node *prev = start;
for (int i = 1; i < obj_amount; i++)
{
struct pmm_node *new = (uint64_t)start + (i * size);
prev->next = new;
prev = new;
}
return h;
}
somethings wrong in this function
the page is valid
dumped the addresses
all valid
I SOLVED IT BUT NOW I TRIPLE FAULT
wtf
guys new address just dropped!
!!!
this is weird
it general protection faulted here
tf
@finite summit i understand how u feel now
this is straight up
torture
This thread is like my prison
and I’m yapping to the cell wall
WHY R U POINTING THERE
😭
STILL
HOW DOES IT EVEN GET THIS ADDRESS
finite summit
The oberrow curse is upon you now
This is worse than what happened to me
Actually debatable
surreal path
This is worse than what happened to me
its worse
i have prints every where
i cant figure out
where its getting this address
im dying
omar help me
this is pain
i cant find
this stupid issue
where is it making up this address
finite summit
sudo pacman -S gdb
surreal path
😠
finite summit
> gdb kernel
> target remote :1234
> breakpoint slab_alloc
> c
wont help me find where it made up the address
okay wiat
wait
finite summit
It'll help more than with prints
surreal path
It'll help more than with prints
not really
since slab_alloc is getitng called
thousands of times
by uacpi
i cant really find the instance where it gets this fake ah address
what the fuckkkk
do the register values looked fucked
i dont know why this is happening
wide nexus
what the fuckkkk
cccccccccccd
surreal path
cccccccccccd
cccccccccccd
wide nexus
based ass value ngl
surreal path
fr
to the point its driving me insane!
at this point i dont know what to do
i've printed every address
everything
oh?
wtf
okay so its attempting to free memory that seems to have corrupted our header
i dont do anything but somehow this is um
i dont know
https://pastebin.com/ZnhNiWZq this is the slab code i guess
maybe one of you guys spot something i didnt idk
im going to sleep i have school trrw
finite summit
@surreal path Take a look into this test function I made for allocators to allow to track the allocation easier
All you'd need to do is break when i == (the allocation that crashes' index) and see what it does
ionic jetty
Hell yeah, another completely failing allocator : )
surreal path
Hell yeah, another completely failing allocator : )
hey 😡
it’s not my fault
My code is simply so pro 😎
surreal path
im in hell
im in hell help me
i even brung my laptop to school
to keep trying to debug the code
I STILL CANNOT FIND IT
i dont get why tf
and my teacher kept asking
me
"did u find the issue yet"
☠️
surreal path
Memory corruption right
something i dont know
i think
but i cannot find the issue in my code
ionic jetty
Debug the exact location of WHERE memory is WHEN corrupted
You could try finding out where and then watch that address with gdb
surreal path
You could try finding out where and then watch that address with gdb
okay sure
ill tell u the output
rigid fable
why do not just use printfs (or whatever) to get the values to see if they are what you expect and use infinite loops to find where it crashes
surreal path
okay back
surreal path
why do not just use printfs (or whatever) to get the values to see if they are w...
im watching the value
hm
surreal path
isn't the new inside the for alllocated on the stack?
yea
surreal path
it seems it is a pointer to a value in your table so no
as in the pointer is created on the stack
rigid fable
yes that is not relevant
surreal path
yea okay
rigid fable
so where is it crashing?
surreal path
so where is it crashing?
somewhere in the slab freelist, its pointing to some non-canoical address
this specfic value 2-smthin i dont have the value in my clipboard but its a value that doesnt make sense, its the same value that causes the crash
every run
elder shoal
Do you have an assert macro
surreal path
the stack trace looks like this
rigid fable
this specfic value 2-smthin i dont have the value in my clipboard but its a valu...
backtrack until you find a good value
surreal path
Do you have an assert macro
?
surreal path
backtrack until you find a good value
no the problem is it shouldnt be pointing to this
it makes zero sense
rigid fable
?
it is a macro which prints the line number of where it is used on a certain condition
surreal path
it is a macro which prints the line number of where it is used on a certain cond...
okay and why do i need this?
elder shoal
To make sure everything is going fine and so you can know when and where something goes wrong
I have a bunch of them around my slab implementation and it has saved me a lot of headaches before
surreal path
that is just pointing tape on the issue
putting*
not fixing it
something is causing this value
someone is like overwritting something where they shouldnt
@kind root its probs memory corruption right?
kind root
yea
rigid fable
if it does not work it is because you are doing something wrong
surreal path
yea
but like ive read through the damn slab allocator code a billion times i dont see the issue where it could be overrwriting something
surreal path
if it does not work it is because you are doing something wrong
i mean clearly
kind root
well look harder
surreal path
well look harder
I AM
kind root
it took oberrow two weeks
ionic jetty
Have you written userspace test @surreal path
surreal path
Have you written userspace test <@787341689333350450>
no
i dont know how to do that
ionic jetty
You copy everything you did
But malloc on some big array
Instead of your physical memory
surreal path
But malloc on some big array
wha
ionic jetty
In your kernels allocator you operate on your ram
In your userspace testing program you do everything the same but just operate on fake ram / an array
surreal path
In your userspace testing program you do everything the same but just operate on...
i printed every fkn address new slab creates
all valid
it HAS to be some kind of memory fuckery
ionic jetty
Are you writing to the allocated blocks
surreal path
Are you writing to the allocated blocks
wdym
ionic jetty
Are you writing to the blocks returned by kmalloc
surreal path
Are you writing to the blocks returned by kmalloc
uacpi is yea of course
ionic jetty
You should try to reproduce your allocator in userspace
ionic jetty
You should try to reproduce your allocator in userspace
If you provide it as a standalone program i‘d even like to test it
ionic jetty
its not me whos making the allocations, its uacpi
Yes but youre doing the work behind the allocations
surreal path
void *uacpi_kernel_alloc(uacpi_size size)
{
char shit[64] = "";
if (size < 1024)
{
return kmalloc(size);
}
else
{
return vmm_region_alloc(align_up(size, 4096), NYA_OS_VMM_PRESENT | NYA_OS_VMM_RW);
}
}
void *uacpi_kernel_calloc(uacpi_size count, uacpi_size size)
{
char shit[64] = "";
if (count * size < 1024)
{
void *man = kmalloc(count * size);
memset(man, 0, count * size);
return man;
}
else
{
return vmm_region_alloc(align_up(count * size, 4096), NYA_OS_VMM_PRESENT | NYA_OS_VMM_RW);
}
}
just letting u know that i do memset the allocations when uacpi calls calloc as required
surreal path
Yes but youre doing the work behind the allocations
yea
ill try to make a userspace program of my slab allocator i suppose
kind root
You can run both uACPI and your allocator in userspace
Oberrow did that and found the bug almost instantly
kind root
Wdym
surreal path
Why wouldn't it
how does it load the acpi tables if its in ring3
kind root
You give it the blob with a virtual address
Look at my tests
Tests_runner.cpp
And interface_impl.cpp
ionic jetty
why does uacpi run in userspace just fine
Uacpi itself doesnt do anything kernel specific afaik
Only your api functions do
So you just „fake“ them
kind root
Uacpi itself doesnt do anything kernel specific afaik
Yup
kind root
Uh no because that needs interrupts
surreal path
Uacpi itself doesnt do anything kernel specific afaik
what do i return when i want to allocate a page
kind root
But I have bytecode tests of course
surreal path
do i just malloc(4096) or somethin
surreal path
lol
was my printf statements
okay so it loads
okay how do i setup uacpi to test @kind root
ionic jetty
look into the uacpi repo into tests ig?
kind root
Np
surreal path
Np
im trying to compile this but like its saying the functions i made dont exist even tho i add the slab.c to the cmakelists thing
i import the header as well
kind root
No idea
rigid fable
im trying to compile this but like its saying the functions i made dont exist ev...
if the functions are written in C++, do you use extern "C" or not?
surreal path
if the functions are written in C++, do you use extern "C" or not?
they arent c++, slab.c is C code
rigid fable
they arent c++, slab.c is C code
maybe the compiler is compiling that as C++
how are you differetiating the compiler between different extension source files?
gcc compiles as C++ by default, it is just that in most cases C code is valid C++ code
surreal path
maybe the compiler is compiling that as C++
no it isnt
rigid fable
no it isnt
unless you specify the -x c flag the compiler compiles code as C++
ah
seems you do see the code as C. But maybe you have not passed the flag
surreal path
even tried
rigid fable
can you upload to github the test code and share a link?
rigid fable
even tried
you are not passing the -x c flag again
surreal path
you are not passing the -x c flag again
rigid fable
what compiler are you using? g++?
surreal path
what compiler are you using? g++?
im using cmake
i dont know what compiler its using
rigid fable
im using cmake
cmake is not a compiler
surreal path
cmake is not a compiler
i know
rigid fable
i dont know what compiler its using
you should use gcc for C files (-x c flag) and g++ for C++ files (gcc can be used for C++ too)
see how to specify a compiler
(I have no idea how cmake works)
can you share the github repo?
surreal path
can you share the github repo?
okay
I FIXED IT
ummm
@kind root what does this mean
rigid fable
I FIXED IT
how did you fix it?
surreal path
how did you fix it?
extern "C"
{
#include "slab.h
}
rigid fable
that should tell you you have serious build problems
surreal path
ummm
oh yeah forgot to init slabs
how im getting the header in kfree?
so how im getting the header
thats removing the 12 bit page offset tho?
???
=================================================================
==949491==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x621000005000 at pc 0x5578c1810218 bp 0x7ffe8e9bed10 sp 0x7ffe8e9bed00
READ of size 8 at 0x621000005000 thread T0
#0 0x5578c1810217 in kfree /home/rayan/Programming/fard/uACPI/tests/runner/slab.c:109
#1 0x5578c17a4103 in uacpi_kernel_free /home/rayan/Programming/fard/uACPI/tests/runner/interface_impl.cpp:226
#2 0x5578c188f42e in uacpi_free_resources /home/rayan/Programming/fard/uACPI/source/resources.c:2018
#3 0x5578c17c77ab in run_resource_tests() /home/rayan/Programming/fard/uACPI/tests/runner/resource_tests.cpp:2226
#4 0x5578c179a016 in main /home/rayan/Programming/fard/uACPI/tests/runner/test_runner.cpp:181
#5 0x7f0a14752d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#6 0x7f0a14752e3f in __libc_start_main_impl ../csu/libc-start.c:392
#7 0x5578c1797244 in _start (/home/rayan/Programming/fard/uACPI/tests/runner/test-runner+0x146244)
0x621000005000 is located 256 bytes to the left of 4096-byte region [0x621000005100,0x621000006100)
allocated by thread T0 here:
#0 0x7f0a1536e887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x5578c180ef98 in init_cache /home/rayan/Programming/fard/uACPI/tests/runner/slab.c:8
#2 0x5578c1810983 in init_slabs /home/rayan/Programming/fard/uACPI/tests/runner/slab.c:164
#3 0x5578c179a011 in main /home/rayan/Programming/fard/uACPI/tests/runner/test_runner.cpp:180
#4 0x7f0a14752d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/rayan/Programming/fard/uACPI/tests/runner/slab.c:109 in kfree
dont understand what any of this means
kind root
```C
=================================================================
==949491=...
Read
surreal path
Read
heap buffer overflow on address 0x621000005000
0x621000005000 is located 256 bytes to the left of 4096-byte region
surreal path
if (kmalloc_cache[i].size == h->size)
Yes
surreal path
struct Header *h = (uint64_t)addr & ~0xFFF;
struct cache *rightcache = NULL;
for (int i = 0; i < 8; i++)
{
if (kmalloc_cache[i].size == h->size)
{
rightcache = &kmalloc_cache[i];
}
}
Debug it
wicked loom
idk if we're debugging the same thing
i have spent the past 2 days trying to figure out why the Vinix slab allocator don't worky
surreal path
i have spent the past 2 days trying to figure out why the Vinix slab allocator d...
relatable !
wicked loom
the Vinix slab is very similar to the Lyre slab so if you took inspiration from either of those, i am so sorry for you
surreal path
the Vinix slab is very similar to the Lyre slab so if you took inspiration from ...
i came up with this design without looking at the lyre source code, i think r4 told me about this design of like having a header at the start of the page and shit and i just implmented that
idk
no it was qwinci
wicked loom
yeah we do the same
we as in Lyre and Vinix collectively
i need to shelve Lyre because honestly keeping track of 2 mostly-the-same-but-sometimes-a-bit-different OSes gets confusing
surreal path
i need to shelve Lyre because honestly keeping track of 2 mostly-the-same-but-so...
Which one do u like more, the one made in the funny V language, or the one made in the funny C language
wicked loom
Vinix
surreal path
why so?
wicked loom
Lyre was translated for the most part from V to C and not by me, so there are certain copying mistakes and sometimes design alterations which make it hard for me to approach it
meanwhile Vinix is mostly made solely by me
the only things that aren't are segregated into driver code for specific shit and not much else in the way of design or other core stuff
surreal path
ah okay
well anyway time to spend the next 24 hours of my life trying to figure out why tf addr & ~0xFFF no worky
wicked loom
if i figure anything out i'll let you know
wicked loom
understandable
surreal path
this bug gives me a brain tumor
wicked loom
btw, a tangential point, but if you take prejudice against V out of the picture, V is a really comfy language for writing a kernel in
at least to me
kind root
well anyway time to spend the next 24 hours of my life trying to figure out why ...
Was addr aligned in the first place?
elder shoal
well anyway time to spend the next 24 hours of my life trying to figure out why ...
is addr 64 bit
wicked loom
not saying you should use it or anything of course, just reporting my experience with the funny 
language
surreal path
is addr 64 bit
yes
wide nexus
btw, a tangential point, but if you take prejudice against V out of the picture,...
how so?
I might give V a try
been wanting to code in something different for a bit now
surreal path
Constants in x86-64 C are 32 bit unless specified
i do (uint64_t) addr & ~0xFFF
wide nexus
but every language out there has some stuff that C just does better
wicked loom
how so?
I might give V a try
it has less clutter than C and a lot of things are baked into the language like dynamic arrays and hashmaps
elder shoal
i do (uint64_t) addr & ~0xFFF
0xfff needs to be 64 bit
wicked loom
btw if you use V for osdev though keep in mind that you need to beat it into submission a bit
it's not very plug-and-play
rigid fable
@surreal path why are you still in voice 0?
surreal path
<@787341689333350450> why are you still in voice 0?
cause i like to be in vc
i am alone 😔
surreal path
0xfff needs to be 64 bit
0xFFFUL?
wide nexus
it's not very plug-and-play
I see, I might give it a try later and look more into it's syntax
wicked loom
btw for me
the problems really only show up if i free the slab allocations
and the funny part is that the corruption garbage written seems to come from a page frame allocator free
which doesn't really check out in any obvious way
wicked loom
is it the same for you?
surreal path
the issue only really showed up
when i took uacpi and my slab allocator to userspace
and ran the test
which showed
that kfree
is the issue
which like doesnt make any sense
wicked loom
what is kfree?
surreal path
it just doesnt make any sense like at all
function for freeing address back into the correct cache slab freelist
wicked loom
do you trash the memory on free?
because for me, even if i do, it still works, as long as i don't try to readd the page to the slab linked list
surreal path
do you trash the memory on free?
deallocate? no i dont deallocate it i just put it back into the freelist atm
wicked loom
as in
overwrite with 0xaa or some random garbage
to catch use-after-free and friends
surreal path
no
wicked loom
try doing it
in your kfree
without actually "freeing" the allocation back to the slab allocator linked list
i keep saying page
i mean allocation
surreal path
so just overwrite the address or the header?
wicked loom
like
overwrite whatever is written at the allocation that you're trying to free
say X tells you to free count bytes at ptr, then memset(ptr, 0xaa, count) before actually freeing the allocation
but don't actually free it
i wanna see if that works for you as well
wicked loom
because if it does we may literally have the same bug which would be kinda funny
surreal path
i did that and like it didnt care until i wanted to try getting the header
surreal path
because if it does we may literally have *the same* bug which would be kinda fun...
it would
wicked loom
odd
elder shoal
Once I thought I had a slab bug but it turned out to be in my pmm because I used a 32 bit int somewhere instead of a 64 bit onw
That was fun to debug
wicked loom
i don't think my pmm is wrong because using it instead of the slab as the kernel allocator makes everything work™️ (at least in appearence)
the problem really just arises when using the slab allocator, and only when freeing
wicked loom
same lol
surreal path
same
ionic jetty
yup
surreal path
yea
wicked loom
unless you go and formally verify everything
surreal path
Was addr aligned in the first place?
wdym?
ionic jetty
I funnily implemented a slab allocator a few days back becuase I wanted to prove to myself that my idea of allocating at pow2round_up(size) alignment was actually sensible
kind root
It's not guaranteed to be page aligned if you use malloc
ionic jetty
I funnily implemented a slab allocator a few days back becuase I wanted to prove...
well I broke it so much that I implemented a "sanitizer" for debugging
surreal path
It's not guaranteed to be page aligned if you use malloc
oh
tawdry mirage
you can use mmap to emulate the pmm
surreal path
okay
kind root
There's memalign
tawdry mirage
mmap(NULL, 0x1000, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE, 0, -1) boom a page :^)
ionic jetty
or just malloc more than you need and then cut off a bit at the front
wicked loom
ok printing out the slab addresses that i get from the slab header on free, they seem to check out
sadly
ionic jetty
dumb question but where do both of you put the slab header? at the front of the slab itself?
elder shoal
I put mine at the top of the page because Im special
wicked loom
beginning of page
surreal path
~~dumb question but where do both of you put the slab header? at the front of th...
beginning of page
wicked loom
basically the first chunk of the slab is allocated to a pointer to the thing
ionic jetty
I decided to steal get inspired by linux idea of a struct page array
works surprisingly great
I can put whatever metadata I want in the page struct
and depending on what it is used at put something else there
thus not needing seperate headers or whatever
surreal path
`mmap(NULL, 0x1000, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE, 0, -1)`...
elder shoal
I decided to ~~steal~~ get inspired by linux idea of a struct page array
I do something like that mostly so I can do some sillier vmm memes in the future
tawdry mirage
oh oops -1, 0 not 0, -1
0xffffffffffffffff is MAP_FAILED
(because NULL is technically a valid return value)
kind root
U didn't run any aml
surreal path
how to do that
kind root
This is basic resource tests
kind root
It does
kind root
ls
kind root
Yeah thats not a leak
surreal path
Yeah thats not a leak
??
surreal path
SO ITS NOT MY SLAB ALLOCATOR HMM?
kind root
It is
surreal path
it didnt crash
kind root
Idk what you did in particular, also wsl aml is tiny
surreal path
Idk what you did in particular, also wsl aml is tiny
what am i supposed to do
kind root
Or actually maybe you leaked your own data somehow idk
Because those are not uACPI leaks
surreal path
okay
kind root
Just download it first
surreal path
kk
kind root
Are you actually freeing stuff
tawdry mirage
could dump the qemu aml
kind root
Or did you comment that out
tawdry mirage
since that's what nyaos is running on
surreal path
feed the dst?
kind root
Yup
kind root
is that bad?
Uhhh this trace looks like it’s calling normal malloc, not your allocator?
surreal path
Uhhh this trace looks like it’s calling normal malloc, not your allocator?
for allocations bigger then 1024
kind root
Oh ok
ionic jetty
Does uacpi maybe have alignment requirements for that?
kind root
Nope
surreal path
kind root
Looks like it works
surreal path
SEEEE
kind root
But im not sure how u get leaks
Its very strange
You sure you're not doing anything strange?
surreal path
all leaks are coming from asan
no
i can give u the code if u want to try it urself
kind root
Run this blob against the vanilla test runner
surreal path
oka
kind root
Any leaks?
surreal path
no leaks
surreal path
Idk how you get them
its because i dont deallocate the memory when im done with them
kind root
So u dont free?
surreal path
i put it back into the slab freelist so its "free"
but i never deallocate a slab or anything
kind root
Hmm
Well then the bug is in your handling of bigger than 1024 bytes
Try making huge slabs
surreal path
how big
kind root
How do u handle them in your kernel
surreal path
How do u handle them in your kernel
if bigger than 1024 then i align it up to a page and allocate
kind root
That logic is probably bugged
surreal path
my vmm?
kind root
Probably somewhere in that neighborhood
kind root
Try it
surreal path
kind root
yeah so if that still works then the bug is in your vmm
surreal path
same amount of leaks
surreal path
yeah so if that still works then the bug is in your vmm
so my slab allocator has been perfect the whole time
kind root
if it survives this then probably
surreal path
what the actual fuck
so i have been debugging the wrong shit for 2 DAYS
2 FUCKING DAYS
☠️
kind root
port vmm to userspace
surreal path
how is that even gonna work
kind root
oberrow did that
surreal path
surreal path
yeah so if that still works then the bug is in your vmm
so is like the vmm somehow corrupting the slab memory or smthin
kind root
who knows
surreal path
how tf does that work
ionic jetty
what exactly does your vmm do
surreal path
allocates a region of virtual memory space, maps x pages to it. returns the base of this region
kind root
how does it allocate
surreal path
if it finds a gap between 2 memory regions that is large enough to fit the region
it sets that up
kind root
sounds error prone
ionic jetty
if it finds a gap between 2 memory regions that is large enough to fit the regio...
How do you track allocated regions
surreal path
How do you track allocated regions
simple freelist
struct vmm_region
{
uint64_t base;
uint64_t length;
uint8_t flags;
struct vmm_region *next;
};
void vmm_region_setup(uint64_t hhdm_pages)
{
size_t kernel_size_in_bytes = (size_t)THE_REAL;
kernel_size_in_bytes = align_up(kernel_size_in_bytes, 4096);
struct vmm_region *node = kmalloc(sizeof(struct vmm_region));
node->base = hhdm_request.response->offset;
node->length = hhdm_pages;
node->flags = NYA_OS_VMM_PRESENT | NYA_OS_VMM_RW;
vmm_head = node;
struct vmm_region *kernel_region = kmalloc(sizeof(struct vmm_region));
kernel_region->base = addr_request.response->virtual_base;
kernel_region->length = THE_REAL;
node->next = kernel_region;
// Regions:
// ------- -------
// - HHDM - - KERNEL -
// ------- -------
// - - - - - - - - - - - - - - ^
// next
serial_print_color("VMM Regions Init!\n", 1);
vmm_region_walk();
}
region gets setup like this
void *vmm_region_alloc(uint64_t size, uint8_t flags)
{
char shit[64] = "";
struct vmm_region *cur_node = vmm_head;
struct vmm_region *prev_node = NULL;
while (cur_node != NULL)
{
// ASSUME REGIONS IN ORDER CAUSE WE COOL :sunglasses:
if (prev_node == NULL)
{
prev_node = cur_node;
cur_node = cur_node->next;
continue;
}
if ((cur_node->base - (prev_node->base + prev_node->length)) >= align_up(size, 4096) + 0x1000)
{
struct vmm_region *new_guy = kmalloc(sizeof(struct vmm_region));
new_guy->base = (prev_node->base + prev_node->length);
new_guy->length = size;
prev_node->next = new_guy;
new_guy->next = cur_node;
cur_node = cur_node->next;
int num_of_pages = align_up(size, 4096) / 4096; // num of pages to alloc :sunglasses:
for (int i = 0; i < num_of_pages; i++)
{
map((uint64_t)pml4 + hhdm_request.response->offset, new_guy->base + (i * 0x1000), pmm_alloc_singlep(), flags);
}
return new_guy->base;
}
else
{
// not enough space for our new region sadly, continue
prev_node = cur_node;
cur_node = cur_node->next;
continue;
}
}
// STILL HERE?
// PANIC CAUSE NO REGIONS CAN FIT VMM REGION WOWIE!
write_color(ctx, "No Free Virtual Address Regions!\n", 4);
asm ("cli");
for (;;)
{
asm ("hlt");
}
}
allocation works like this
ionic jetty
```C
void vmm_region_setup(uint64_t hhdm_pages)
{
size_t kernel_size_in_byte...
Should I be questioning THE_REAL
surreal path
Should I be questioning THE_REAL
gotten from the linker script
SECTIONS
{
/* We wanna be placed in the topmost 2GiB of the address space, for optimisations */
/* and because that is what the Limine spec mandates. */
/* Any address in this region will do, but often 0xffffffff80000000 is chosen as */
/* that is the beginning of the region. */
. = 0xffffffff80000000;
AMONG_US = .;
.text : {
*(.text .text.*)
} :text
/* Move to the next memory page for .rodata */
. += CONSTANT(MAXPAGESIZE);
.rodata : {
*(.rodata .rodata.*)
} :rodata
/* Move to the next memory page for .data */
. += CONSTANT(MAXPAGESIZE);
.data : {
*(.data .data.*)
} :data
/* Dynamic section for relocations, both in its own PHDR and inside data PHDR */
.dynamic : {
*(.dynamic)
} :data :dynamic
/* NOTE: .bss needs to be the last thing mapped to :data, otherwise lots of */
/* unnecessary zeros will be written to the binary. */
/* If you need, for example, .init_array and .fini_array, those should be placed */
/* above this. */
.bss : {
*(.bss .bss.*)
*(COMMON)
} :data
/* Discard .note.* and .eh_frame since they may cause issues on some hosts. */
/DISCARD/ : {
*(.eh_frame)
*(.note .note.*)
}
THE_REAL = . - AMONG_US;
}
These naming conventions should be prosecuted
Calling anything in your codebase AMONG_US is just criminal
surreal path
#ihavenoselfrespect
elder shoal
Thats kinda sussy
kind root
#ihavenoselfrespect
Lol at least your self aware
ionic jetty
#ihavenoselfrespect
Remorse is the first step to becoming a better human
kind root
Comment out and find out
surreal path
Comment out and find out
still same issue
kind root
Unlucky
surreal path
wait no
njow its faulting here?
gpr'd here???
but theres no invalid address here
oh
now thats getting fucked
@kind root wtf
kind root
Idk
kind root
A bug
surreal path
yes but
why is memory getting so corrupted
the slab allocator was proven to work in userspace
surreal path
why are you trying to initialize the char array?
yea fair but it doesnt make a difference either way
rigid fable
and what is itoah? Is not it just an integer to ascii? What is that h
surreal path
its still not the issue
someone is fucking my memory
rbx has the weird ass address
i dont know what to do anymore
i tested the slab allocator in userspace it worked, i dont know whats ruining my memory
rigid fable
i tested the slab allocator in userspace it worked, i dont know whats ruining my...
unitialized values?
if you do not zero everything, then instead of getting value zero and failing the if nulls it uses garbage values
that's my guess
surreal path
so should i memzero my memory before i "free it"
rigid fable
I am specifically talking about the memory where the allocator variables are stored
tawdry mirage
what you should do is bring in managarm/frigg, and have one c++ file to use frg::slab_pool and expose it to the rest of the kernel :^)
surreal path
what you should do is bring in managarm/frigg, and have one c++ file to use frg:...
i dont want to use someone elses allocator
if theres something wrong with the code then its my fault and i should keep trying til i fix it
im really at a deadend here
tawdry mirage
yeah i'm joking
surreal path
yea i know
kind root
Add more printfs
surreal path
i did
kind root
Not enough
kind root
Then you would see where it goes wrong
kind root
we tested it in userspace remember?
Im not talking about slabs
Other components as well
surreal path
sure
tawdry mirage
actually, i just remembered
an even better method for emulating mapping memory
memfd for allocating physical pages, mmap to map them into the address space
(replace memfd with tmpfs files if you really want to)
surreal path
every single region vmm makes
all look valid
i dont know what to do anymore this is pain
finite summit
advancement made! oberrow hell
finite summit
that means it's not the allocator
finite summit
at least when u tested ur allocator in userspace
and btw it did
It's probably the VMM
Does your VMM have an interdependecy on the allocator
if it does that might be your problem
surreal path
Does your VMM have an interdependecy on the allocator
kinda
surreal path
ye
surreal path
why would that be a problem
finite summit
Because
infinite recursion if no space could be found for all regions
rather caches
in the allocator
surreal path
infinite recursion if no space could be found for all regions
i check if theres no space
and i just halt
and error out
oh you mean the caches
finite summit
yes
finite summit
Then that shouldn't be your problem then
surreal path
yea
surreal path
I have.
surreal path
Zero memory
i dont zero memory when i free
i only zero memory on calloc
as uacpi says to do
surreal path
okay
surreal path
finite summit
don't paste the output
surreal path
finite summit
what about all the null dereferences
surreal path
if a cache isnt inited
some undefined things will happen
thats what these are saying basically
all these null dereferences are if a cache ISNT inited
but i always init them
so this isnt the problem
finite summit
what if a cache has some garbage memory address because you never zeroed it
or some slab in the cache
surreal path
what if a cache has some garbage memory address because you never zeroed it
will i zero memory i free then?
surreal path
so zero my slabs before i use them?
finite summit
yes
surreal path
alr
WAIT THAT COULD ACTUALLY BE THE ISSUE!!!
WAIT
WAIT WAIT WAIT
IM GONNA TEST THIS
NO MORE GARBAGE MEMORY ADDRESSES?
LETS GO!
but now
it page faults here
finite summit
definitely allocator issue
If an allocator works in userspace but not in kernel mode
probably an issue with zeroed memory
surreal path
probably an issue with zeroed memory
???
surreal path
wait i dont memzero when i allocate with the vmm
kind root
but i zeroed all my memory
You sure large allocations are zeroes as well?
surreal path
could that be also an issue?
kind root
Yup
kind root
Yes
finite summit
Well partially unimplemented uACPI
kind root
Also you dont call namespace initialize last time I checked
surreal path
i am
kind root
Ok
surreal path
LOOK
@kind root @kind root @kind root @kind root @kind root @kind root @kind root @kind root
jaunty hingeBOT
cinder plinth
um why is he timed out
finite summit
spam
cinder plinth
ah nvm im an idiot
finite summit
You're welcome
finite summit
Lets see who's the next to be put into oberrow hell
surreal path
😭 😭
bro gonna torture the next osdev
also our vmm_free function seems to be broken
lemme fix it
finite summit
ah yes our
surreal path
our
finite summit
communism in NyaOS confirmed
finite summit
surreal path
the page
finite summit
could have something to do with the analyzer
warnings
Check if it says anything in the vmm_free function'
finite summit
do you intend to set freelist to him->next
surreal path
void vmm_region_dealloc(uint64_t base)
{
char shit[64];
struct vmm_region *cur_node = vmm_head; // find prev node and node after it
struct vmm_region *prev_prev_node;
while(cur_node != NULL)
{
if (cur_node->base == base)
{
if (cur_node->next)
{
prev_prev_node->next = cur_node->next;
}
int num_of_pages = align_up(cur_node->length, 4096) / 4096;
for (int i = 0; i < num_of_pages; i++)
{
uint64_t phys = unmap((uint64_t)pml4 + hhdm_request.response->offset, cur_node->base + (i * 0x1000));
pmm_free_singlep((uint64_t)phys + hhdm_request.response->offset);;
}
free(cur_node);
return;
}
else
{
prev_prev_node = cur_node;
cur_node = cur_node->next;
continue;
}
}
// REGION DOESNT EXIST WOWIE!
write_color(ctx, "Region Provided doesn't exist!\n", 4);
asm ("cli");
for (;;)
{
asm ("hlt");
}
}
yep
page fault happened there cause of same noncanoical address issue due to
vmm_region_dealloc
finite summit
So are allocator bugs just called oberrow hell now
surreal path
😎
finite summit
His was a simple bug though
surreal path
took me 3 days
kind root
Yes
surreal path
just goota fix this vmm bug