#uACPI - a portable and easy-to-integrate ACPI implementation

1 messages · Page 3 of 1

fiery turtle
#

Is it all in free_package?

hollow elm
#

not all

fiery turtle
#

Hmm

hollow elm
#

another one is ```
0x50300009ac34 is located 4 bytes inside of 32-byte region [0x50300009ac30,0x50300009ac50)
freed by thread T0 here:
#0 0x5631214da536 in free /var/tmp/portage/sys-libs/compiler-rt-sanitizers-17.0.6/work/compiler-rt/lib/asan/asan_malloc_linux.cpp:52:3
#1 0x563121524d68 in uacpi_kernel_free /tmp/uacpi/tests/runner/interface_impl.cpp:217:5
#2 0x56312154d6e4 in free_object /tmp/uacpi/source/types.c:666:5
#3 0x56312154d6e4 in free_chain /tmp/uacpi/source/types.c:711:13
#4 0x56312154d6e4 in uacpi_object_unref /tmp/uacpi/source/types.c:749:9

previously allocated by thread T0 here:
#0 0x5631214da7de in malloc /var/tmp/portage/sys-libs/compiler-rt-sanitizers-17.0.6/work/compiler-rt/lib/asan/asan_malloc_linux.cpp:69:3
#1 0x563121525082 in uacpi_kernel_alloc /tmp/uacpi/tests/runner/interface_impl.cpp:188:17
#2 0x563121525082 in uacpi_kernel_calloc /tmp/uacpi/tests/runner/interface_impl.cpp:222:17
#3 0x56312154c571 in uacpi_create_object /tmp/uacpi/source/types.c:313:11

fiery turtle
#

Interesting

#

Send that over too

fiery turtle
#

Thx

hollow elm
#

i think i'll let the fuzzer run over night

#

due to the larger input corpus

fiery turtle
#

That would be great

hollow elm
#

curious ```
[uACPI][WARN] invalid table 'DSDT' checksum!
[uACPI][TRACE] load of 'DSDT' (OEM ID 'ATC' OEM Table ID 'Cofbej')
[uACPI][TRACE] write to [_SB_.TP80] (2 bytes) TableData[0x0000000000000001] = 0x0
AddressSanitizer:DEADLYSIGNAL

==1950122==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000001 (pc 0x556a1f6d71e9 bp 0x7ffcff823501 sp 0x7ffcff823490 T0)
==1950122==The signal is caused by a WRITE memory access.
==1950122==Hint: address points to the zero page.
#0 0x556a1f6d71e9 in memory_write /tmp/uacpi/source/default_handlers.c:270:35
#1 0x556a1f6d71e9 in table_data_region_do_rw /tmp/uacpi/source/default_handlers.c:322:8

#

lmao another aml blob that just segfaults iasl

#
Program received signal SIGSEGV, Segmentation fault.
AcpiDmCheckForSymbolicOpcode (Op=Op@entry=0x5555556cc4c0, Info=Info@entry=0x7fffffffd030) at ../../../source/components/disassembler/dmcstyle.c:429
429           Target = Argument2->Common.Next;
(gdb) p Argument2
$1 = (ACPI_PARSE_OBJECT *) 0x0
hasty plinth
#

sure is, its here https://github.com/DeanoBurrito/northport, although if you're looking for how I'm using uacpi its not in the repo yet. I'm using it as a loadable driver, and am still playing around with how I want the api to look on the kernel side.

north holly
#

I wanted to do that in my previous kernel, I don't think it's a good idea

#

The code was going to be messy

hasty plinth
#

I think its a good idea meme

north holly
#

ok then gl

hasty plinth
#

ty

fiery turtle
fiery turtle
#

okay yeah this isnt a use after free

#

this is use of uninitialized pointer

#

the fuzzer made it so _STA returned nothing

#

in that case apparently nothing in the code overwrites the pointer to NULL

#

which is unfortunate

#

log with the fix applied

fiery turtle
#

these are some insane blobs

north holly
#

Funnily enough, if the code path was simple enough the static analyzer might've been able to tell you what happened

fiery turtle
#

uacpi_execute_control_method must set the pointer to null if no return value was provided and the method exited successfully

#

that's just what any sane api would do

north holly
#

Tbf this path would've been buried in the 100s of one's like it

fiery turtle
#

yup

hollow elm
fiery turtle
#

i wonder how many of these is just uninitialized pointer because of missing return value

hollow elm
#

a good chunk i presume

fiery turtle
#

probably

hollow elm
#
[uACPI][TRACE] load of 'DSDT' (OEM ID 'DELL\x' OEM Table ID 'UsbCTabl')
AddressSanitizer:DEADLYSIGNAL
=================================================================
==3975158==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x55def6b6cdc0 bp 0x000000000007 sp 0x7ffea5f45180 T0)
==3975158==The signal is caused by a READ memory access.
==3975158==Hint: this fault was caused by a dereference of a high value address (see register values below).  Disassemble the provided pc to learn which register was used.
    #0 0x55def6b6cdc0 in bit_copy /tmp/uacpi/source/io.c:80:21
fiery turtle
#

but cool nonetheless

hollow elm
#

wym unknown address

fiery turtle
#

lol

hollow elm
#

a good chunk of the crashes are also my fault

fiery turtle
#

wdym?

hollow elm
#

on the assert here

#

by trying to map >512 pages at once

fiery turtle
#

ohh

hollow elm
#
[uACPI][TRACE] read from [\_SB_.PCI0.LPCB.LPC1] (1 bytes) PCI_Config[0x000000000000006B] = 0xFF
/tmp/uacpi/source/uacpi.c:634:23: runtime error: shift exponent 65 is too large for 32-bit type 'int'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /tmp/uacpi/source/uacpi.c:634:23 in 
invalid free size: originally allocated 56 bytes, freeing as 32
fiery turtle
#

that's an interesting one

hollow elm
#

indeed

#

hm it's in uacpi_eval_sta

#

so possibly related to the uninit pointer

fiery turtle
#

almost certainly

#
diff --git a/source/interpreter.c b/source/interpreter.c
index d6693a0..1aa24a8 100644
--- a/source/interpreter.c
+++ b/source/interpreter.c
@@ -5680,6 +5680,9 @@ uacpi_status uacpi_execute_control_method(
     }

 out:
+    if (out_obj != UACPI_NULL)
+        *out_obj = UACPI_NULL;
+
     if (ctx->ret != UACPI_NULL &&
         ctx->ret->type != UACPI_OBJECT_UNINITIALIZED) {
         uacpi_object_ref(ctx->ret);
#

this is the fix i made locally

#

see if that fixes like all of those

hollow elm
#

i wonder if i could teach afl that crashes in memory_read/memory_write are uninteresting

fiery turtle
#

probably

hollow elm
#

okay that seems to fix all the interesting crashes

fiery turtle
#

unlucky

#

but good find nonetheless

#

Does it still try to shift by 65 after that?

hollow elm
#

no that went away too

fiery turtle
#

oh ok

hollow elm
#

or at least i don't see it

fiery turtle
#

yeah that shifts the type member

#

since it was a bogus pointer it was shfting by a bogus number

hollow elm
#

i wonder how we come up with a read from 0x000000ff

#

i can't see how is_physical_pointer can say it's not physical

fiery turtle
#

where did you see that?

hollow elm
#
[uACPI][WARN] invalid table 'DSDT' checksum!
[uACPI][TRACE] load of 'DSDT' (OEM ID 'DUC' OEM Table ID 'DkcVfdy')
AddressSanitizer:DEADLYSIGNAL
=================================================================
==263676==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000000ff (pc 0x55cc0f480538 bp 0x7ffeba639cb0 sp 0x7ffeba639bc0 T0)
==263676==The signal is caused by a READ memory access.
==263676==Hint: address points to the zero page.
    #0 0x55cc0f480538 in memory_read /tmp/uacpi/source/default_handlers.c:254:16
fiery turtle
#

out of bounds write because of a previous mapping being smaller and then that trashed this pointer?

#

potentially

#

because 0xFF seems like what IO reads return

hollow elm
#

hmm

fiery turtle
#
 void* uacpi_kernel_map(uacpi_phys_addr addr, uacpi_size size)
 {
+    std::printf("Mapping 0x%016" PRIX64 " with size %zu\n", addr, size);
+
#

try this

#

see if it maps the same thing multiple times

hollow elm
#

oh yeah the same addr is mapped twice

#

second time with a larger size

fiery turtle
#

yup..

hollow elm
#

so that's the realloc thing you mentioned

fiery turtle
#

yup

hollow elm
#

bit underwhelming to only find 1 real bug but that's still 1 bug less

fiery turtle
#

its a pretty important bug so yeah

#

i wonder if that unblocks more bugs

#

i also want to make aborts in methods unwind back to table level code so that will unlock even more bugs potentially

vast kestrel
#

Afl looks cool ngl

#

I should try and use it for my dotnet runtime

fiery turtle
#

yeah its pretty nice

north holly
#

@fiery turtle I get some warnings in uACPI related to variables possibly being used uninitialized.

uACPI/source/interpreter.c:2844:9: warning: 'arg1_buf.ptr' may be used uninitialized [-Wmaybe-uninitialized]
 2844 |         uacpi_memcpy(dst_buf + arg0_buf->size, arg1_buf.ptr, arg1_buf.len);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
uACPI/source/interpreter.c:2834:41: note: 'arg1_buf.ptr' was declared here
 2834 |         struct object_storage_as_buffer arg1_buf;
      |                                         ^~~~~~~~
uACPI/source/interpreter.c:2837:18: warning: 'arg1_buf.len' may be used uninitialized [-Wmaybe-uninitialized]
 2837 |         buf_size = arg0_buf->size + arg1_buf.len;
      |         ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
uACPI/source/interpreter.c:2834:41: note: 'arg1_buf.len' was declared here
 2834 |         struct object_storage_as_buffer arg1_buf;```
#

same warning around interpreter.c:1714:17

#

actually I might as well give you the entire log

#

you can ignore all analyzer warnings, those are for my kernel

#

everything in the log until it says [27%] Built target uacpi

fiery turtle
#

nah its a false positive

#

i can add a default switch case to make it shut up tho

north holly
#

I just love it though when the static analyzer yells at me because of nullptr dereferences as a result of a new call

#

It's so annoying

fiery turtle
#

@hollow elm I think I came up with a genius idea

diff --git a/tests/runner/interface_impl.cpp b/tests/runner/interface_impl.cpp
index cee0874..ae387f4 100644
--- a/tests/runner/interface_impl.cpp
+++ b/tests/runner/interface_impl.cpp
@@ -116,22 +116,7 @@ uacpi_status uacpi_kernel_pci_write(
     return UACPI_STATUS_OK;
 }

-static bool is_physical_address(uacpi_phys_addr addr, uacpi_size size)
-{
-#ifdef _WIN32
-    return IsBadReadPtr((void*)addr, size);
-#else
-    // https://stackoverflow.com/questions/4611776/isbadreadptr-analogue-on-unix
-    int nullfd = open("/dev/random", O_WRONLY);
-    bool ok = true;
-
-    if (write(nullfd, (void*)addr, size) < 0)
-        ok = false;
-
-    close(nullfd);
-    return !ok;
-#endif
-}
+bool g_expect_virtual_addresses = true;

 static
 std::unordered_map<void*, std::pair<uacpi_phys_addr, size_t>>
@@ -141,7 +126,7 @@ static std::unordered_map<uacpi_phys_addr, void*> phys_to_virt;

 void* uacpi_kernel_map(uacpi_phys_addr addr, uacpi_size size)
 {
-    if (is_physical_address(addr, size)) {
+    if (!g_expect_virtual_addresses) {
         auto it = phys_to_virt.find(addr);
         if (it != phys_to_virt.end()) {
             virt_to_phys_and_refcount[it->second].second++;
diff --git a/tests/runner/test_runner.cpp b/tests/runner/test_runner.cpp
index 891257e..d36daa6 100644
--- a/tests/runner/test_runner.cpp
+++ b/tests/runner/test_runner.cpp
@@ -131,6 +131,8 @@ static void run_test(
     uacpi_status st = uacpi_initialize(&params);
     ensure_ok_status(st);

+    g_expect_virtual_addresses = false;
+
     st = uacpi_install_notify_handler(
         uacpi_namespace_root(), handle_notify, nullptr
     );
hollow elm
#

incredible

fiery turtle
#

lmao

fiery turtle
#

@hollow elm i made an insanely overengineered system that should be safe against everything

#

we should try fuzzing that

#

im about to merge it in a bit

#
@@ -118,31 +120,60 @@ uacpi_status uacpi_kernel_pci_write(

 bool g_expect_virtual_addresses = true;

+struct mapping {
+    void *virt;
+    uacpi_size size;
+
+    bool operator==(const mapping& m) const
+    {
+        return size == m.size;
+    }
+};
+
+template <>
+struct std::hash<mapping>
+{
+    size_t operator()(const mapping& m) const
+    {
+        return m.size;
+    }
+};
+
 static
 std::unordered_map<void*, std::pair<uacpi_phys_addr, size_t>>
 virt_to_phys_and_refcount;

-static std::unordered_map<uacpi_phys_addr, void*> phys_to_virt;
+static std::unordered_map<uacpi_phys_addr, std::unordered_set<mapping>>
+phys_to_virt;

 void* uacpi_kernel_map(uacpi_phys_addr addr, uacpi_size size)
 {
     if (!g_expect_virtual_addresses) {
         auto it = phys_to_virt.find(addr);
         if (it != phys_to_virt.end()) {
-            virt_to_phys_and_refcount[it->second].second++;
-            return it->second;
+            auto mapping_it = it->second.find({ nullptr, size });
+
+            if (mapping_it != it->second.end()) {
+                virt_to_phys_and_refcount[mapping_it->virt].second++;
+                return mapping_it->virt;
+            }
+
+            std::printf("WARN: remapping physical 0x%016" PRIX64
+                        " with size %zu\n", addr, size);
         }

         void *virt = std::calloc(size, 1);
+        mapping m = { virt, size };
+
         virt_to_phys_and_refcount[virt] = { addr, 1 };
-        phys_to_virt[addr] = virt;
+        phys_to_virt[addr].insert(m);
         return virt;
     }

     return reinterpret_cast<void*>(addr);
 }

-void uacpi_kernel_unmap(void* addr, uacpi_size)
+void uacpi_kernel_unmap(void* addr, uacpi_size size)
 {
     auto it = virt_to_phys_and_refcount.find(addr);
     if (it == virt_to_phys_and_refcount.end())
@@ -151,7 +182,18 @@ void uacpi_kernel_unmap(void* addr, uacpi_size)
     if (--it->second.second > 0)
         return;

-    phys_to_virt.erase(it->second.first);
+    auto phys_it = phys_to_virt.find(it->second.first);
+    auto mapping_it = phys_it->second.find({ nullptr, size });
+    if (mapping_it == phys_it->second.end()) {
+        std::printf("WARN: cannot identify mapping virt=%p phys=0x%016" PRIX64
+                    " with size %zu\n", addr, phys_it->first, size);
+        return;
+    }
+
+    phys_it->second.erase(mapping_it);
+    if (phys_it->second.empty())
+        phys_to_virt.erase(it->second.first);
+
     std::free(it->first);
     virt_to_phys_and_refcount.erase(it);
 }
#

basically this

#

it now successfully runs that blob you sent yesterday

#

okay merged

#

now I expect 0 crashes in the fuzzer

hollow elm
#

nice

fiery turtle
#

inb4 instant crash

hollow elm
#

for this round of fuzzing i'm enabling cmplog

#

which hooks comparisons and sends the values being compared against to afl which then tries to inject them into the fuzzer output

#

hopefully this should make it so more valid instructions appear

fiery turtle
#

Hmm

#

Im not sure what that means but if it makes the fuzzing more efficient sounds great!

#

Thank you

lilac knoll
#

ig it means that if you have a branch if (x == 42) then instead of afl randomly trying values for x until it hits 42, it'd get a hint that it should shove the value 42 in there

hollow elm
#

yeah

fiery turtle
#

Ooh nice

hollow elm
#

i'm thinking it'll figure that it should shove more valid aml opcodes into the input

fiery turtle
#

Yeah thats definitely interesting

left orbit
#

personally i think part of what made fuzzing great was the fuzzer throwing random opcodes everywhere so you can find weird ass edge cases with uacpi

#

also i kinda forgot but thanks for sized frees :^)

fiery turtle
#

Npnp

left orbit
#

not my uacpi kernel api free is no longer a stub

#

although i do not believe it was called either way

fiery turtle
fiery turtle
left orbit
#

i absolutely do not utilize any of the public apis just yet

#

ill replace table iteration with uacpi shortly

fiery turtle
#

Not even init?

#

Lol

left orbit
#

oh no i do call init

fiery turtle
#

And namespace load as well?

left orbit
#

i call uacpi_initialize and uacpi_install_notify_handler

#

uhhhh

fiery turtle
#

Yeah there's uh

left orbit
#

oh shit i totally did not read

#

the test runner fully

fiery turtle
#

U dont need the notify handler too

left orbit
#

yeah let me throw in some more calls and see what happens

fiery turtle
#

Its mostly for testing

#

Look at oberrows kernel or managarm init sequence

#

I should really make a tutorial

left orbit
#

is eval("\MAIN") required?

fiery turtle
#

Nope its the test runner abi

hollow elm
left orbit
#

yeah i figured, just wanted to ask

hollow elm
#

or at least that's the idea

left orbit
#

idk why i thought it was gonna generate fully compliant aml

#

lmao

hollow elm
#

no way in hell it's doing that

fiery turtle
#

Well sometimes it does

hollow elm
#

did you see the kind of output it makes

fiery turtle
#

Else { else { else {

hollow elm
#

if it is even decompilable with iasl

lilac knoll
#

i wonder how much acpica has been fuzzed

hollow elm
#

i am inadvertently fuzzing iasl as well :^)

fiery turtle
#

It died almost instantly as well I think?

fiery turtle
#

Probably not at all

hollow elm
#

i was about to say "i wonder how hard it is to go from aml -> taking over linux due to bugs in acpica" but then i remembered aml can poke at arbitrary memory already

fiery turtle
#

Yeah its trusted code basically

left orbit
#
[  0] (main) err: Kernel panic: switch on corrupt value
[  0] (debug) err: Stack backtrace:
[  0] (debug) err:   0xFFFFFFFF800827F7: <no symbol info> at kernel/src/mutex.zig:17
[  0] (debug) err:   0xFFFFFFFF800B96B4: uacpi_kernel_acquire_mutex at kernel/src/uacpi.zig:306
[  0] (debug) err:   0xFFFFFFFF8001F8ED: enter_method at kernel/./uacpi/source/interpreter.c:4232
[  0] (debug) err:   0xFFFFFFFF800167F6: prepare_method_call at kernel/./uacpi/source/interpreter.c:4892
[  0] (debug) err:   0xFFFFFFFF80015F97: uacpi_execute_control_method at kernel/./uacpi/source/interpreter.c:5635
[  0] (debug) err:   0xFFFFFFFF8000E896: uacpi_eval at kernel/./uacpi/source/uacpi.c:618
[  0] (debug) err:   0xFFFFFFFF8000E8E7: uacpi_eval_typed at kernel/./uacpi/source/uacpi.c:629
[  0] (debug) err:   0xFFFFFFFF80012813: uacpi_eval_sta at kernel/./uacpi/source/utilities.c:620
[  0] (debug) err:   0xFFFFFFFF8000F1E1: sta_eval at kernel/./uacpi/source/uacpi.c:460
[  0] (debug) err:   0xFFFFFFFF8000E54D: do_sta_ini at kernel/./uacpi/source/uacpi.c:504
[  0] (debug) err:   0xFFFFFFFF8005288A: uacpi_namespace_for_each_node_depth_first at kernel/./uacpi/source/namespace.c:476
[  0] (debug) err:   0xFFFFFFFF8000DFF0: uacpi_namespace_initialize at kernel/./uacpi/source/uacpi.c:0
[  0] (debug) err:   0xFFFFFFFF8008F0AF: init at kernel/src/uacpi.zig:41
[  0] (debug) err:   0xFFFFFFFF8008EE73: main at kernel/src/main.zig:155
[  0] (debug) err:   0xFFFFFFFF8008F2FA: _start at kernel/src/main.zig:111
[  0] (debug) err:   0x0000000000000000: <no symbol info> at ??:0```
#

something seems to be going really wrong meme

#

i'll have to fix my mutex bullshit, but thats for tomorrow

hollow elm
#

oh oops lmoa ```
[+] Found 44 unique tuples across 4578 files.
[!] WARNING: All test cases had the same traces, check syntax!
[+] Narrowed down to 1 files, saved in 'fuzz-in/'.

#

i threw out all blobs that time out after 0.8s

hollow elm
#

i forgot to tell it to pass the filename to the test runner so it reduced all the inputs to just one

fiery turtle
#

Lol

left orbit
#

holy SHIT i think i might just be retarded !!!

hollow elm
#
$ afl-cmin -i hw-blobs/ -o fuzz-in/ -T all -- _build-nocmplog/test-runner 
``` vs ```
$ afl-cmin -i hw-blobs/ -o fuzz-in/ -T all -- _build-nocmplog/test-runner @@
fiery turtle
#

Makes sense

fiery turtle
#

Who knows maybe test runner segfaults at startup sometimes

left orbit
#
/// Returns a pointer to undefined memory.
/// Call `destroy` with the result to free the memory.
pub fn create(self: Allocator, comptime T: type) Error!*T {```
#

HJAHA!!!!

#

WOW

#

WHO WOULD HAVE THOUGHT

#

[ 0] (phys) info: uacpi-info: namespace initialization done: 35 devices, 0 thermal zones, 1 processors

hollow elm
left orbit
#

uninitialized allocations strike again

hollow elm
#

and less than 1 in 12 thousand on master

fiery turtle
#

Fuzzing the clone syscall

lilac knoll
fiery turtle
#

Zig I think

hollow elm
#

hm i fucked something up

fiery turtle
#

Everything just hangs?

hollow elm
#

it's running very slow

fiery turtle
#

Huh

hollow elm
#

which is confusing because i threw out all the hw blobs that timed out

#

even before feeding it into afl-cmin

fiery turtle
#

Are you compiling llvm perhaps KEKW

hollow elm
#

nah lol

fiery turtle
#

Strange

hollow elm
#

am i losing it, the cmplog variant runs fine

fiery turtle
#

Lol

hollow elm
#

okay no it also experienced slowdowns

#

im gonna run afl-tmin on the input corpus

#

and then maybe cmin again on the minimized files

#

i love gnu parallel ```
$ find ./ -type f | parallel afl-tmin -i {} -o ../fuzz-in-min/{/} -- ../_build-nocmplog/test-runner @@
Academic tradition requires you to cite works you base your article on.
If you use programs that use GNU Parallel to process data for an article in a
scientific publication, please cite:

Tange, O. (2024, January 22). GNU Parallel 20240122 ('Frederik X').
Zenodo. https://doi.org/10.5281/zenodo.10558745

This helps funding further development; AND IT WON'T COST YOU A CENT.
If you pay 10000 EUR you should feel free to use GNU Parallel without citing.

More about funding GNU Parallel and the citation notice:
https://www.gnu.org/software/parallel/parallel_design.html#citation-notice

To silence this citation notice: run 'parallel --citation' once.

fiery turtle
#

Lmao

hollow elm
#

damn i should've passed --bar to parallel

#

to get a progress bar

fiery turtle
#

Lol yes

hollow elm
#

okay i think i'm gonna look into it tomorrow

fiery turtle
#

@hollow elm did it crash?

hollow elm
#

havent had any crashes yesterday but i didnt do any long campaigns

fiery turtle
#

well thats progress already anyway

#

pretty nice

fiery turtle
#

for now this only has initialization tutorial but ill add some code examples later

north holly
#

Take some from my previous kernel :^)

fiery turtle
#

I might add a list of kernels to look at for examples

fiery turtle
#

Don't u just love when github ci runners randomly break every fucking week for no reason

fiery turtle
#

that's okay i fixed it caret

hollow elm
#

didn't know there was an env var

rustic compass
fiery turtle
#

yeah thats on the todo list

hasty plinth
#

whats the recommended course of action for handling the fatal type of firmware request? should that result in a panic or is it safe to keep running for a bit?

fiery turtle
hasty plinth
#

OK cheers, I saw managarm doing the same

fiery turtle
#

Also fixed a few misc things in uacpi, including namespace node attach order

jaunty fox
#

i will implement shutdown at some point

#

uacpi will make the doing it easy it's the preparing that won't be

fiery turtle
#

yeah, unmounting everything and stuff is definitely not easy

fiery turtle
jaunty fox
#

proper shutdown is one of those features which i don't think i have ever seen a hobby OS

#

i'm not sure about unmounting either, which goes with it

fiery turtle
#

yup

#

best u get is just how mangarm currently does it

#

power button press == instant shutdown

hollow elm
#

we should probably implement sync sometime :^)

fiery turtle
#

just sync probably won't be enough

#

but yeah

hollow elm
#

well yeah ideally we'd wire the power button to tell userspace to shutdown

fiery turtle
#

yeah

#

also usually power button is configured to actually trigger sleep instead

#

or bring up a gui prompt

hollow elm
#

but in the current situation having all managed memory objects (objects used to implement page caches) be told to do a writeback at least would be a good idea

#

if we want to just power off immediately

fiery turtle
#

but yeah all of that comes down to routing it to userspace

wind fiber
#

Yeah

#

That reminds me I have some shutdown related work still standing. I should get back to work and get that shit fixed

fiery turtle
#

Made method aborts while loading tables non-fatal (aka only the call chain is aborted and the table keeps loading)

hollow elm
#
[uACPI][TRACE] write to [\PCI0.UHCI.TEST.PCIR] (1 bytes) TableData[0x0000000000000000] = 0x7
AddressSanitizer:DEADLYSIGNAL
=================================================================
==1140720==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x5655286ea9d3 bp 0x7fff6db14201 sp 0x7fff6db14170 T0)
==1140720==The signal is caused by a WRITE memory access.
==1140720==Hint: address points to the zero page.
    #0 0x5655286ea9d3 in memory_write /tmp/uacpi/source/default_handlers.c:267:34
    #1 0x5655286ea9d3 in table_data_region_do_rw /tmp/uacpi/source/default_handlers.c:322:8
#

i suppose there's not much you can do about this?

fiery turtle
#

hmm

#

how the f is the pointer 0

hollow elm
#

well the connection between TableData[0x0000000000000000] and the pointer being 0x000000000000 seems obvious? but i don't know how it actually works

fiery turtle
#

oh actually i know exactly how this happened

#

so table data opregions are created via TableRegionDataOp

#

under the hood it uses the same opregion structure

#

but

#

this aml created it via OpregionOp by hijacking the address space type

#

address space type happened to match internal enum that corresponds to tabledata

#

and table data is mapped as just a plain virtual address

#

so it did not further validation on that

#

basically this "Internal type"

hollow elm
#

hm yeah ```
OperationRegion (PCIR, 0xFE, 0x00, Arg0)
Field (PCIR, AnyAcc, NoLock, Preserve)
{
REG0, 38
}

fiery turtle
#

lmao

hollow elm
#

iasl managed to actually decompile it :^)

fiery turtle
#

technically this is invalid i think, because its a reserved address space

#

but yeah i guess i should add validation for this in the code

#

to at least check that its not 0xFE

hollow elm
#

that's the only crash so far, after about an hour

#

but i'm only using the tests as input

fiery turtle
#

technically this is a real bug, so nice

#

hmm well i guess its OEM defined

#

so maybe a u8 is not enough to represent it

#

idk

hollow elm
#

what's the TableData type used for?

fiery turtle
hollow elm
#

ah

#

literally what it says on the tin

fiery turtle
#

ye

#

these are basically system memory, but the base is a virtual address

#

at least in uacpi

hollow elm
#

makes sense

fiery turtle
#

Now that I think about why am I even doing _REG for it, thats not even a real opregion type

#

Good thing this bug was found

hollow elm
#

another crash found ```
[uACPI][WARN] error during _REG execution for operation region \PCI0.UHCI.TEST.PCIR@0x506000000b60: invalid argument
AddressSanitizer:DEADLYSIGNAL

==2406755==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x562631cbcd83 bp 0x7fff8eebe010 sp 0x7fff8eebdf20 T0)
==2406755==The signal is caused by a READ memory access.
==2406755==Hint: address points to the zero page.
#0 0x562631cbcd83 in memory_read /tmp/uacpi/source/default_handlers.c:245:16
#1 0x562631cc1063 in dispatch_field_io /tmp/uacpi/source/io.c:229:11
#2 0x562631cc1063 in access_field_unit /tmp/uacpi/source/io.c:288:12
#3 0x562631cbf7fd in uacpi_read_field_unit /tmp/uacpi/source/io.c:364:15

#

i can't disassemble it, it has invalid opcodes, and if i just patch them to 0x00 iasl segfaults instead :^)

#

but it seems related, \PCI0.UHCI.TEST.PCIR is what used to be the TableData opregion in the previous crashing input

fiery turtle
#

can u send both crashes pls?

#

but yeah read is traced after the read so

#

there isnt like "about to read"

hollow elm
#

makes sense

#

so far there's 5 saved crashes but afaics they are all on a TableData opregion

fiery turtle
#
--- a/source/interpreter.c
+++ b/source/interpreter.c
@@ -1080,6 +1080,9 @@ static uacpi_status handle_create_op_region(struct execution_context *ctx)
     op_region = obj->op_region;

     op_region->space = item_array_at(&ctx->cur_op_ctx->items, 1)->immediate;
+    if (op_region->space == UACPI_ADDRESS_SPACE_TABLE_DATA)
+        return UACPI_STATUS_AML_BAD_ENCODING;
+
#

try this

hollow elm
#

yeah that fixes all the crashes

fiery turtle
#

ok nice

fiery turtle
#

I'm adding core API that should be used during initial namespace device discovery to bind corresponding drivers

#

Im thinking ill add a mode to the test runner to run this against every node, perhaps this will add better coverage for the fuzzer @hollow elm

hollow elm
#

sounds like a good idea

fiery turtle
#

maybe if its a device ill also run _CRS and _PRS against it

hollow elm
#

it'd probably also be useful for managarm for exposing all the legacy devices over mbus :^)

fiery turtle
#

yeah definitely

#

this api i basically stole from acpica

#

linux uses it for initial bus enumeration

#

Also i want to add a CI mode that decodes all 500 AML blobs from that repo and runs the test runner against all of them

#

sounds like useful regression testing

vast kestrel
#

Is there a reason why the EC driver is not part of uacpi

fiery turtle
#

yes

#

because a proper implementation requires very tight coupling with kernel primitives

#

as well as being able to handle platform specific EC quirks

#

uacpi is not gonna take on that responsibility and provide a shitty half-working implementation

fiery turtle
#

this is completely outside of scope of what uacpi is doing

#

and uacpi philosophy is either do it well or dont do it at all

north holly
#

I thought you said an EC driver would be easy

fiery turtle
#

it is trivial for a blocking EC driver that works on 80% of hardware

#

a proper async one that handles everything is quite a bit more complex tho

fiery turtle
#

this file has so many bugzilla links

vast kestrel
#

Makes sense

#

I just always see the same EC driver in hobby osdev and am like "this looks tiny"

#

But seeing Linux explains everything :^)

#

Same vibe as xhci

fiery turtle
#

Yup

fiery turtle
#

Today i decided that i will add more tables to acpi.h

#

So that users dont have to roll their own

#

ill start with madt

#

but ill also do hpet and a few other

north holly
#

I got it, now what? /j

fiery turtle
#

stabilize it so it doesnt segfault when u blow on it

north holly
#

bet

#

will do

#

(after school)

fiery turtle
#

also when rewrite 5

north holly
#

When I figure out if the kernel is truly unfixable

#

When it's damaged beyond repair

#

I think I might try testing the VMM a bit (after school)

#

With large page allocations

#

and frees (those are largely untested)

#

SetProtection is so trivial there is no point in testing

#

But I use that in the driver loader and it works fine

#

Actually, the reason it took me so long to finish the VMM for this rewrite is because I wasn't working on the kernel

#

So if I work on the kernel more, a rewrite could be feasible

#

Anyway enough littering this thread

fiery turtle
#

sure sounds good

north holly
#

I also kind of made a mistake where IRQs are non-preemptible like I originally wanted them to

#

(because otherwise the kernel shits itself)

fiery turtle
#

jesus madt has so many entry types now

#

took a while to write all of them out

jaunty fox
#

are the RISC-V entries official now?

#

i know drwe de vault was very upset that ACPI was being pushed for risc-v

tired crater
#

i know i know dumb question but who is acpi talking to when someone says it interacts with firmware? Like does it talk to some seperate controller running some system control code or does it talk to some special device or what does it really do

fiery turtle
fiery turtle
#

there's a data structure in ACPI NVS that has SMM opcode & args, that is configured and invoked by the AML bytecode

#

then bytecode waits for the smm to reply

#

and propagates the reply to the os etc

tired crater
#

I see thanks for clarifying

fiery turtle
#

np

fiery turtle
#

i think the riscv structures might get added in acpi 6.6

#

6.5 is 3 years old at this point

fiery turtle
jaunty fox
fiery turtle
#

lmao

lilac knoll
#

probably mad because it makes the kernel complicated

fiery turtle
#

yes, for a hobby os like linux a fully static description of the state of the system at boot is totally enough

lilac knoll
#

but kernels are complicated so that's a cringe complaint

jaunty fox
#

granted it won't be doing much for you unless you lean in to what it offers

fiery turtle
#

tbh if u use something like uacpi u can implement suspend/resume in like 1000 loc

#

its not crazy difficult

#

plus some assembly for wake vector

jaunty fox
#

i would like to try it at some point

fiery turtle
#

i might do a PoC example for managarm evetually

#

for S1 suspend u dont even need assembly wake vector or saving ACPI NVS

#

it just resumes from where it left off

#

granted u dont save much power that way

lilac knoll
# jaunty fox

it just triggers me because it reminds me of the casey muratori rant where he talks about hardware complexity

fiery turtle
#

yeah id say that complaint is more of a skill issue

lilac knoll
#

he's upset that hardware is complicated

jaunty fox
#

"the world was better before branch predictors" sort of take?

lilac knoll
#

it's an insane rant

#

let me find the vid though it's 3h long

#

honestly kinda

jaunty fox
#

i will not watch a 3hr rant

lilac knoll
#

casey's take on acpi would be: 'oh my god shutting down the computer should just be a single memory access!!!!!'

fiery turtle
#

and he complains about acpi complexity

lilac knoll
jaunty fox
#

it's designed to be low in memory use though

#

i looked at it before

fiery turtle
#

how many loc is it

#

i bet its liek 30k

lilac knoll
jaunty fox
#

it wouldn't work well for a kernel unless you reconstructed a lot of it (drop its custom caching, integrate it with your kernel's, drop its vfs, make it possible to use without holding a global lock around every read/write)

fiery turtle
#

yeah from what im seeing its targeting embedded

#
❯ cloc --vcs=git .
      90 text files.
      90 unique files.
       3 files ignored.

github.com/AlDanial/cloc v 1.90  T=0.09 s (916.7 files/s, 305922.9 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C                               30           3411           2940          14145
C/C++ Header                    32            988           2819           3301
make                             2            191              2            555
CMake                           19             68             29            296
Markdown                         1             45              0            199
YAML                             3              5              1             38
-------------------------------------------------------------------------------
SUM:                            87           4708           5791          18534
-------------------------------------------------------------------------------
#

okay yeah that library is the size of uacpi

hollow elm
#

i imagine drew went for it since bunnix is just a unix-like os speedrun

jaunty fox
#

the question is why he has abandoned helix

#

his microkernel-based system

fiery turtle
#

I also sometiems get tired of complex code and having to do everything properly and just end up wanting to speedrun something like that

jaunty fox
#

i fell into that mode and regretted it

#

well

#

i don't regret it as such, it's very inspiring

#

running x11 was fun but i need to make this thing elegant, teachable

fiery turtle
#

true

#

garbage just doesnt scale and u get tired of it

jaunty fox
#

the benefit apart from the fun of making it run exciting software was perhaps the experience and familiarity it offered

fiery turtle
#

makes sense

jaunty fox
#

implementing something poorly can be a good prelude to implementing it well if you are too slow to turn out something beautiful the first time

fiery turtle
#

oberrow@

fiery turtle
#

added a whole bunch of tables

#

anything else people use these days?

hasty plinth
#

SLIT would be nice if you've got SRAT, but I don't know how many are actually using those 🤔

fiery turtle
#

yeah SLIT should be added def

hollow elm
#

there's a pr for lai about adding the tpm tables, but i'm not sure how useful it is or how well that fits

fiery turtle
#

any table is useful, i think eventually uacpi should have every table in that header

#

ill take a look at the tpm table

#

Also numa aware allocators in managarm when

hollow elm
#

:^)

rustic compass
wind fiber
# jaunty fox

I remember that, I was there. Pretty sure I attended this specific talk lol

jaunty fox
#

from time to time i get interested in extreme scaling on NUMA machines

#

so i want SLIT and SRAT

fiery turtle
#

I made a nice namespace dumper in the test runner

#

me when GOOG000A ps/2 keyboard

tired crater
fiery turtle
#

but i will

rain nimbus
fiery turtle
loud ice
fiery turtle
#

@hollow elm do u remember the argument that i made for why its difficult to implement proper while timeouts?

#

im thiking abut how to design it now and i dont see any problems

#

liek i dont remember what the problem was last time

hollow elm
#

that the aml can trigger calls to kernel functions and those take an unknown amount of time?

fiery turtle
#

hmm i dont think so?

#

well like an Event wait i guess

#

but thats not related to While timeouts

#

i think

#

anyway i added a start_ticks to every While codeblock, now i just check it at the beginning of that While

#

either when Continue or the end of block

hollow elm
#

nice

#

but yeah other than that i can't remember either

fiery turtle
#

Yay

vagrant hull
#

you really should make a uACPI test image

fiery turtle
#

managarm caret

vagrant hull
#

i wanted to test it on this new board i got but running managarm is tedious lol

#

yeah, tedious

fiery turtle
#

yeah but a proper test image that supports everything uacpi needs will be an absolute ton of work

vagrant hull
#

is the latest CI image fine?

#

of managarm

fiery turtle
#

otherwise it would be a piece of crap

fiery turtle
vagrant hull
#

alright

#

i'll test using that

fiery turtle
#

give it a shot

#

if the latest ci image is like within the last week

vagrant hull
#

it's from yesterday

fiery turtle
#

thats good enough!

fiery turtle
#

like a new pc motherboard?

vagrant hull
#

yeah

#

it's an MSI PRO B650M-B

#

i got it because it's one of the few AM5 motherboards with separate PS/2 keyboard and mouse

#

(it works well btw)

fiery turtle
#

nice

vagrant hull
#

ok i tried it

#

it seems to work

#

it gets to "waiting for /dev/sda0" and gets stuck there (of course it does)

#

but pressing the power button makes the machine shut down

fiery turtle
#

yeah if it says waiting for sda it made it to userspace

#

and xhci died probably

fiery turtle
#

Fuck, never mind

#

The way While works right now is the code block is re-created every time when it gets jumped to

#

so the context of the while that was just being executed is lost

#

this will need some refactoring

fiery turtle
#

Managarm does have USB drivers btw

verbal herald
#

yes but it always default to sda0

#

not sdb0 or something

fiery turtle
#

Thats not why it doesn't work tho

verbal herald
#

sda0 usually corresponds to sata

#

with sdb0 being usb

#

shouldn't there be a boot option to use sdb0 instead like linux

fiery turtle
#

It corresponds to SATA only if u have a SATA drive

#

And thats not a problem in managarm anyway

#

It can boot like this too

verbal herald
#

yes but it always defaults to sda0 all the time

#

which is sata and not usb

#

if you have a sata drive

#

idk what the drive name is if you have nvme

#

maybe just like linux where its nvme0p0

#

so unless you only have usb, it always defauts to sata or whatever

hollow elm
#

i mean ideally we'd just run udev in init-stage1, let it set up /dev/disk/by-uuid and just mount by uuid using symlinks from there

fiery turtle
#

Yup

hollow elm
#

shouldn't even be that hard to do now, since the /dev/disk/by-uuid part was already working, and i recently merged some old patch that removes the size limitation for the initramfs

fiery turtle
#

the idea is to preserve the previous while expiration and code offset before re-evaluating it

#

Here's a blob that infinitely polls some HW register

#

previously it would run forever

#

And another one from @vast kestrel

hollow elm
#

okay so i tried managarm on my laptop

#

and uacpi initialized fine, and there were even some queries happening and the aml was doing some notification (thermal zone related judging by the name), but unfortunately the power button didn't work

hollow elm
#

unfortunately i can't check if the uacpi init just failed since i didn't get into weston

#

looking at a disassembly of the acpi tables, it seems to use the new kind of power button

#

oh it seems to be for WMI

fiery turtle
#

Does it have a power button object in the namespace?

#

Would be interesting to see full logs ofc

#

Also pls send the dump

fiery turtle
#

could also be related to _INI order, which I recently changed (but not yet merged into managarm)

#

so try git fetch && git checkout origin/master in the mangarm ports (although that will break find_by_signature a bit)

hollow elm
hollow elm
fiery turtle
#

that would be great, and a dsdt dump would be awesome too

hollow elm
#

yeah i can post it later

fiery turtle
#

nice

hollow elm
fiery turtle
#

@hollow elm is there an ECDT table as well?

hollow elm
#

no ecdt, linux says ```
[ 0.964029] ACPI: _SB_.PCI0.SBRG.EC0_: Boot DSDT EC used to handle transactions

fiery turtle
#

okay hmm

#

and when you press the power button no query is produced? @hollow elm

hollow elm
#

nop, nothing happens

fiery turtle
#

okay yeah its definitely the AML thinking we're a legacy os

hollow elm
#

there are some queries happening, and a notify that goes ignored for _TZ_.THRM, but nothing for the power button

fiery turtle
#

do the fn+whatever keys do anything?

hollow elm
#

hm good q, didn't think to try them

#

mmm i hate usb

#

qemu-system-x86_64 -m 2G -device qemu-xhci -device usb-host,vendorid=0x13fe,productid=0x4200 boots, but on my laptop the usb msd driver doesn't seem to pick the usb stick up

fiery turtle
#

lol

fiery turtle
hollow elm
#

ac i can't test because the battery is kinda dead meme

fiery turtle
#

anyway its definitely a result of misconfiguration

#

could be order thats currently in managarm

#

could be some opregion is read incorrectly

#

they use indexfields a lot in your laptop

#

can you give the latest uacpi master a try before i do more debugging pls

hollow elm
#

yeah ofc

fiery turtle
#

thanks

#

also pls check that there's 100% no ECDT there ls /sys/firmware/acpi/tables | grep ECDT

#

because we had a similar issue in qwinci's laptop and that was because of that

hollow elm
#
qookie@selenium ~ λ ls /sys/firmware/acpi/tables | grep ECDT
qookie@selenium ~ λ ls /sys/firmware/acpi/tables
APIC  CRAT  dynamic  FIDT  IVRS   SSDT10  SSDT13  SSDT2  SSDT5  SSDT8  VFCT
BGRT  data  FACP     FPDT  MCFG   SSDT11  SSDT14  SSDT3  SSDT6  SSDT9  WSMT
CDIT  DSDT  FACS     HPET  SSDT1  SSDT12  SSDT15  SSDT4  SSDT7  TPM2
qookie@selenium ~ λ 
fiery turtle
#

yeah ok

hollow elm
#

/sys/firmware/acpi/tables/dynamic/ and /sys/firmware/acpi/tables/data/ are empty

fiery turtle
#

because it does feature detection in the _REG method

#

just like qwinci

#

so if thats called early it will set the bare minimum features

#

but if there's no ECDT that should be correct

fiery turtle
#

yeah basically the power button is unconditionally notified for query 28

            Method (_Q28, 0, NotSerialized)  // _Qxx: EC Query, xx=0x00-0xFF
            {
                Notify (PWRB, 0x80) // Status Change
            }
#

so its 100% EC programmed incorrectly by AML

#

but why is that I currently have no idea

hollow elm
#

i come bearing new findings

fiery turtle
#

Please share!

#

Lol

hollow elm
#

Fn+F2 (brightness down) and Fn+F3 (brightness up) trigger ec queries 16 and 17 respectively, which end up notifying the vga acpi node (which has no listeners), and this only works once (and io-apic irq 7 is left unacknowledged so perhaps it requires the host's ps/2 driver to work),
at random times query 128 happens, which notifies the thermal zone, but again no listeners,
opening and closing the lid triggers query 138, which notifies the lid object, but again no listeners,
holding the power button for a while (but not long enough that it triggers a hard power off, letting go just before it shuts down) triggers query 153, which does nothing (?),
short pressing the power button does nothing

fiery turtle
#

Yeah no listeners just means nothing in managarm hooked it up

#

Long press shutting down makes sense

#

Because it invokes smm

#

But yeah what you said confirms my theory

hollow elm
#

i'd expect it to be implemented in the chipset itself, but the query just before the hard shutdown happens is interesting

fiery turtle
#

Just need to figure out why it thinks were below windows 7

fiery turtle
hollow elm
#

yeah but it doesn't seem to notify anything

fiery turtle
#

Because managarm doesn't install any notify handlers for those devices

#

Its supposed to be listentened to by a host driver

hollow elm
#

i mean, there was no warning saying there are no listeners

fiery turtle
#

What device was it notifying?

hollow elm
#

oh _Q99 is literally a noop ```
Method (_Q99, 0, NotSerialized) // _Qxx: EC Query, xx=0x00-0xFF
{
}

fiery turtle
#

Lol

#

Didn't hook it up I guess

hollow elm
#

forgor

fiery turtle
hollow elm
#

yes

#

or well latest as of like an hour and a half ago if you pushed anything

fiery turtle
#

Nah I didn't

hollow elm
fiery turtle
#

I think it doesn't support Notify interface for it

hollow elm
#

god bless hp ```
Device (PS2K)
{
Method (_HID, 0, NotSerialized) // _HID: Hardware ID
{
If (W8OS ())
{
Return ("*HPQ8001")
}
Else
{
Return ("PNP0303")
}
}

fiery turtle
#

Lmao

vast kestrel
#

WeightOS

hollow elm
#

ig they made a custom driver for win8+?

#

what for i don't want to even think

fiery turtle
#

They did

vast kestrel
#

EC fun

fiery turtle
#

No idea why

vast kestrel
#

most likely custom memes they do which goes over the PS2 interface

hollow elm
#

also i wonder, do firmware developers have some special asl compiler that accepts longer names and just shortens them or do they actually suffer through 4 character names

vast kestrel
#

afaik they only use 4 letter names

hollow elm
#

ig the fact things like W7OS are even legible makes that pretty clear

vast kestrel
#

WsevenOS

fiery turtle
#

There isn't any extension or anything

vast kestrel
#

I mean, they could have made a simple custom preprocessor

hollow elm
#

yeah i was thinking as a non-standard thing on top of asl

vast kestrel
#

that just hex(os.urandom(2))

hollow elm
#

that'd make debugging annoying though ig

#

unless you teach the os about the random 4 characters -> name mapping

vast kestrel
#

The thing I wonder about is how they make the WMI memes

hollow elm
#

the wmi bios settings list made me curious

#

because it lists things not exposed in the actual bios

fiery turtle
vast kestrel
#

it allows windows (or well, HP prop programs) to change the settings

hollow elm
#
            Package (0x0F)
            {
                "Manufacturing Programming Mode Counter", 
                "Place holder ", 
                "\\Place holder for Path", 
                One, 
                Zero, 
                One, 
                0x0376, 
                0x03, 
                " ", 
                " ", 
                " ", 
                Zero, 
                Zero, 
                0x0A, 
                Zero
            }
vast kestrel
#

Place holder for Path

#

that might actually be a read-only counter and not necesarily a write

hollow elm
#

probably yeah but still kinda interesting

left orbit
#

that is some cursed ass aml

#

but i don't think one should expect laptop firmware manufacturers to put in much effort and/or think too hard

keen marsh
#

If my kernel does not yet support SMP can i just declare the functions from the api headers for locking as always returning true?

jaunty fox
#

so they are still important

keen marsh
#

Yeah but isnt the sleeping in case they were already locked? ("which cant happen")

left orbit
#

i think the return value specifies whether you could acquire it before the timeout

jaunty fox
jaunty fox
#

i defer to the author's advice

fiery turtle
#

As long as you return false

#

If its already acquired

fiery turtle
#

In reality probably won't matter

hollow elm
# hollow elm ``` Package (0x0F) { "Manufacturing Prog...
            If (SRCM (MFLG, "MPMLock", 0x07))
            {
                If (SCMP (Local0, "Serial Number"))
                {
                    DerefOf (N00D [Arg0]) [0x03] = One
                }

                If (SCMP (Local0, "Product Name"))
                {
                    DerefOf (N00D [Arg0]) [0x03] = One
                }

                If (SCMP (Local0, "UUID"))
                {
                    DerefOf (N00D [Arg0]) [0x03] = One
                }
#

curious

#

SRCM is a strncmp afaics

keen marsh
#

And cant just return "aquiring lock was successful" every time

hollow elm
#

idk why i am digging into this but this is very interesting

fiery turtle
#

I cant promise it won't break, but for truly single threaded workflows yea

#

Since aml mutexes are recursive anyway

hollow elm
#

they only mentioned not having SMP

fiery turtle
#

Okay so I would definitely debug this if I had the hardware, there are lots of things to check or dump, but idk how interested you are in that

#

uACPI doesn't have a way to override dsdt but would be interesting to recompile this with debug prints

#

And e.g force write WIN7 in EC as 1

#

Etc

#

Tons of things you could do

hollow elm
#

i'd be up for some debugging

#

i also need to figure out the parameter error i'm getting in the xhci driver when configuring the endpoint

#

but for that i think i have an idea from when i was talking with nooby about his xhci driver

fiery turtle
#

Yeah if we had working xhci we could also properly inspect logs

#

Right now I guess thats impossible as well

hollow elm
#

i am forgetting to set some fields in the device contexts :^)

hollow elm
#

and the ps2 driver

#

although not sure if less would work on the kernel console :^)

fiery turtle
#

Lol yeah

#

Idk how badly this xhci init is broken to tell

hollow elm
#

iirc i am missing the ESIT and polling interval fields (oops meme)

#

ofc qemu doesn't care about the polling interval

#

even for hid

fiery turtle
#

Oh if you can fix it that would be amazing, if not we can come up with something else

#

@hollow elm and pressing the power button does do something for your Linux right?

hollow elm
#

yeah on linux it is handled and passed on to user space

fiery turtle
#

Ok ok just checking who knows

hollow elm
#

and triggers the kde shutdown prompt

fiery turtle
#

Yeah makes sense

#

Also I think we unconditionally enable the fixed event for the power button (without checking fadt), maybe this somehow messes with the ec

#

Could comment that out but I doubt thats it

hollow elm
#

i hate the xhci spec

vast kestrel
#

its fine™️

hollow elm
#

"Refer to section 6.2.3.8 for more information."
the 6.2.3.8 is a link, click it, get taken to the section
"Refer to section 4.14.2 for the definition of an “ESIT” [...]"
the 4.14.2 is not a link

#

at the very least 4.14.2 is the correct section

#

there are some references that are off because they added stuff inbetween

fiery turtle
#

Lmao

hollow elm
#

here's an example: in table 6-21:

TD Size. This field provides an indicator of the number of packets remaining in the TD. Refer to
section 4.10.2.4 for how this value is calculated.
section 4.10.2.4: "4.10.2.4 Babble Detected Error"
section 4.11.2.4: "4.11.2.4 TD Size"

fiery turtle
#

Lol

vast kestrel
#

Yeah I had that exact thing happen lol

#

Like exactly with TD size

fiery turtle
fiery turtle
#
Method (^BN00, 0, NotSerialized)
{
    Return (Zero)
}

Method (_BBN, 0, NotSerialized)  // _BBN: BIOS Bus Number
{
    Return (BN00 ())
}

least insane AML

verbal herald
#

slightly rewriting it too with codes from the main zig version translated into c

left orbit
#

managarm is a thing already

#

its much more advanced, basically ruling out kernel being broken at this point

#

no need to maintain a test kernel in addition to uacpi

hasty plinth
#

is there a particular reason detecting pointer size is done this way?

#

as opposed to something like sizeof(void*)?

#

Im asking because it causes my riscv tests to fail nooo

fiery turtle
#

I dont even remember where this is used, id have to check

fiery turtle
hasty plinth
#

but yeah, riscv support would be helpful (for me lol)

fiery turtle
#

Cant you just define it explicitly for the time being

#

It checks ifndef

hasty plinth
#

ah it does, nice

fiery turtle
#

Ye

hasty plinth
#

fwiw thats the only thing that prevents it from building on riscv

#

cant say if it runs just yet because clang generates relocations I havent implemented 😅

fiery turtle
#

Nice

#

Oh also define UACPI_REDUCED_HARDWARE 1

#

For riscv

jaunty fox
#

very kind of you both to explore risc-v with uacpi

fiery turtle
jaunty fox
#

i would like to work on a risc-v keyronex against but i decided to wait until risc-v acpi is a bit more established (you needed a custom qemu for it to be any use, last i worked on it)

fiery turtle
#

Yeah riscv stuff is not yet officially there

hasty plinth
#

tbh its a totally selfish goal for me, I want my kernel to be as uniform as it can - will see how that goes when it gets uacpi loaded 😛

#

yeah riscv/acpi is a huge WIP

hasty plinth
fiery turtle
#

This strips out huge chunk of code for supporting full acpi hardware

#

Its not mandatory to disable it ofc

#

Its autodetected otherwise

jaunty fox
#

i had a quick google search for risc-v acpi and someone is coping and seething about it

#

you posted cringe mdp_cs

fiery turtle
#

Giant skill issue

jaunty fox
#

there's more to it than acpi.sys and acpi-ca

#

the "easier to implement drivers for each power IC" bit also led me down the garden path, i thought he was being sarcastic at first

fiery turtle
#

This is just wrong on so many levels

jaunty fox
#

no one will ever deny acpi is complex, but such is the price of flexibility

fiery turtle
#

True

jaunty fox
#

it's a far cry from a format loosely inspired by Open Firmware's device tree but turned into a static blob

fiery turtle
#

Yeah

fiery turtle
#

Which you must have for the full package

#

At this point the only bad thing about managarm is poor driver stability

#

But that dies in userspace luckily

fiery turtle
#

try #if sizeof(void*) == 4

lilac knoll
#

ah

#

why do you need that though

tired crater
#

Because pointer size varies

mortal yoke
tired crater
#

Have you tested on 32 bit machines copyobject abuser

mortal yoke
#

that would be pretty portable

#

(between 32-bit and 64-bit)

lilac knoll
fiery turtle
#

that would have to be replacable by the user etc

fiery turtle
#

but uacpi is tested in 32-bit mode in normal ci

mortal yoke
fiery turtle
#

are those defined in stdint.h?

mortal yoke
#

yes

fiery turtle
#

ig i could do that

#

but then again im not sure thats better than checking the architecture

mortal yoke
#

at least it would work on more architectures without you needing to add them there

#

other than that probably not

fiery turtle
#

but there's only so many architectures with acpi

#

itanium, x86, arm, and risc-v

vast kestrel
#

Like, even if the acpi init pass can't really test much when it dies somewhere else down the chain

fiery turtle
vast kestrel
#

Does it reach deep enough for testing power button and stuff?

fiery turtle
#

boot as in reach userspace

#

yeah

vast kestrel
#

It doesn't on my PC

fiery turtle
#

thats in the kernel so that almost always works

vast kestrel
#

It dies on USB

hollow elm
#

usb is in userspac

#

e

vast kestrel
#

And on my laptop it dies before even reaching the kernel

fiery turtle
vast kestrel
#

Idk it's in a panic state

#

anyways it's still not a nice test image for quickly checking a bunch of functionality AMshrug

fiery turtle
#

well a proper test image would need a full blown kernel with a sophisticated scheduler, so thats like 10k loc of code

vast kestrel
#

Do you need a sophisticated scheduler tho

fiery turtle
#

can't test events otherwise

vast kestrel
#

I can take the core of my C# kernel very easily

#

It has a scheduler with events, it has a simple memory management

fiery turtle
#

well if it has a higher success rate at booting than managarm and you actually port uacpi there then that can work as a test image as well caret

vast kestrel
#

I might try it if I ever get free time :^)

fiery turtle
#

that would be great

hollow crescent
#

no way he said that

jaunty fox
fiery turtle
#

finally got around to extending the test suite to run the 500 publically available acpi dumps

#

a lot of them timeout because they infinitely poll some MMIO or IO regs

#

thats where my loop timeout detection PR comes in as well

hollow elm
#

what's the 20 fails, timeouts?

fiery turtle
#

yeah, all of them are timeouts

hollow elm
#

nice

fiery turtle
#

Unfortunately 150 of these 500 don't have the AML to extract for DSDT

#

only its disassembled representation

#

which might not be compilable

#

or at least its not possible to even extract with any existing tools

#

so thats kinda unfortunate

#

fuuck this doesnt work on windows lol

#

ill have to modify the repo

#

ok that was just one file, great

#

okay so with the timeout branch only 3 are failing

#

and its really annoying blobs

#
Method (RR_M, 1, Serialized)
{
    If ((Acquire (MUEC, 0xFFFF) == Zero))
    {
        Local0 = Arg0
        Local1 = (Local0 & 0xFF)
        Local0 >>= 0x08
        Local0 &= 0xFF
        CDT2 = Local1
        CDT1 = Local0
        CMD1 = 0x80
        ESEM = 0x0F
        Local0 = 0x7F
        While ((Local0 && CMD1))
        {
            Sleep (One)
            Local0--
        }

        If ((CMD1 == Zero))
        {
            Local0 = EDA1 /* \_SB_.PC00.LPCB.EC0_.EDA1 */
        }
        Else
        {
            Local0 = Ones
        }

        Release (MUEC)
        Return (Local0)
    }

    Return (Ones)
}
#

it does 127 sleeps for 1 ms

#

and this shit is called a lot of times

#

so the blob takes longer than 10 seconds to load and test runner thinks it timed out

north holly
#

Firmware developers are very smart as we can see

fiery turtle
#

1 second total sleep time in the end

#

hmm on linux tihs only takes 1.8 seconds to load

#
runner/build-linux-64bits/test-runner   0.33s user 0.25s system 31% cpu 1.837 total
#

with UBSAN+ASAN

#

why is it so slow on windows

#

std::this_thread::sleep_for(std::chrono::milliseconds(msec));

#

like

#

maybe this takes longer on windows for some reason

#

Yayy all passes if i port my while timeout commit

#

thats with ubsan and asan

#

the only problem is on windows where sleep takes longer for some reason in debug mode

rustic compass
#

maybe allow longer timouts in debug mode?

fiery turtle
#

the timeout is in the python test runner

#

i could bump it, yeah

#

still annoying

#

its currently set to 10 seconds

hollow crescent
fiery turtle
fiery turtle
#

me when firmware developers

#

and their error paths

#
Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
{
    If ((TPTY == One))
    {
        Name (SBFB, ResourceTemplate ()
        {
            I2cSerialBusV2 (0x0015, ControllerInitiated, 0x00061A80,
                AddressingMode7Bit, "\\_SB.I2CA",
                0x00, ResourceConsumer, , Exclusive,
                )
        })
    }

    If ((TPTY == 0x02))
    {
        Name (SBFS, ResourceTemplate ()
        {
            I2cSerialBusV2 (0x002C, ControllerInitiated, 0x00061A80,
                AddressingMode7Bit, "\\_SB.I2CA",
                0x00, ResourceConsumer, , Exclusive,
                )
        })
    }

    Name (SBFI, ResourceTemplate ()
    {
        GpioInt (Level, ActiveLow, ExclusiveAndWake, PullUp, 0x0000,
            "\\_SB.GPIO", 0x00, ResourceConsumer, ,
            )
            {   // Pin list
                0x0009
            }
    })
    If ((TPTY == One))
    {
        Return (ConcatenateResTemplate (SBFB, SBFI))
    }

    If ((TPTY == 0x02))
    {
        Return (ConcatenateResTemplate (SBFS, SBFI))
    }
}
#

brooo are u fucking kidding

#

lmao

#
Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
{
    If (GTPM ())
    {
        Return (Zero)
    }

    If (GCTP ())
    {
        Return (ResourceTemplate ()
        {
            Memory32Fixed (ReadWrite,
                0xFED40000,         // Address Base
                0x00005000,         // Address Length
                )
            IO (Decode16,
                0x0CB0,             // Range Minimum
                0x0CB0,             // Range Maximum
                0x08,               // Alignment
                0x10,               // Length
                )
        })
    }
    Else
    {
        Return (Zero)
    }
}

Thats not how you _CRS LULW

#

Brooo hand rolled fucking resource template

Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
{
    Name (NAM, Buffer (0x0F)
    {
        "\\_SB.SDHB.BRCM"
    })
    Name (SPB, Buffer (0x0C)
    {
        /* 0000 */  0x8E, 0x18, 0x00, 0x01, 0x00, 0xC0, 0x02, 0x00,  // ........
        /* 0008 */  0x00, 0x01, 0x00, 0x00                           // ....
    })
    Name (END, Buffer (0x02)
    {
         0x79, 0x00                                       // y.
    })
    Concatenate (SPB, NAM, Local0)
    Concatenate (Local0, END, Local1)
    Return (Local1)
}
#

[uACPI][ERROR] invalid/unsupported serial connection type 192

#

i guess i should support that

#

Well ACPICA doesnt support it

#

so i wont either, whatever

vast kestrel
#

maybe just make it a warning instead

fiery turtle
#

well i have to be able to convert it somehow

#

for it to be a warning

#

because this aborts the _CRS invocation

vast kestrel
#

hmmm, you also want a way for drivers to have custom types in there probably

fiery turtle
#

probably, but acpica managed to not support it for 30 years and be fine

#

i guess no one uses it

vast kestrel
#

is that your inspiration

left orbit
#

ah, so that's (_CRS) what uacpi_get_current_resources calls and gives back to you? (message from nyaux chat, dont wanna pollute it)

vast kestrel
fiery turtle
#

like from a user perspective linux doesnt need that and it supports like all hw out there

vast kestrel
#

I do wonder what windows do

fiery turtle
#

probably some proprietary driver that handles this serial connection

fiery turtle
#

there's also possible_resources (_PRS)

#

which is a list of possible values that can be used to override the current resources

left orbit
#

setting everything up properly is quite involved lol

fiery turtle
#

yeah

#

and this resource conversion thing has a bytecode VM for converting them

#

its pretty insane

#

here's one for IRQ for example

#

Some of these public blobs do absolutely insane things

#

crazy uacpi survives all of that

#

good fuzzing experience because of qookie i guess

fiery turtle
#

Added a test case for infinite while loops

#

600k iterations with ASAN+UBSAN and O0 is pretty decent

#

(in 3 seconds)

hollow elm
#

can aml integers be arbitrarily large?

fiery turtle
#

only 64 bits

hollow elm
#

or are they just a fixed-size int

#

ah

fiery turtle
#

yeah

#

idk if its worth guarding against 64-bit overflow lmao

#

unless this runs on nasa quatum computer

fiery turtle
hollow elm
#

ah right i remember something about 32-bit integers and acpi

fiery turtle
#

yeah its an annoying backwards compat thing

#

also if DSDT is rev 1 and SSDTs are 2 everything is still done as 32 bits

#

this can be seen on real hw too

hollow elm
#

huh

fiery turtle
#

basically only DSDT revision matters

hollow elm
#

do you actually support that?

fiery turtle
#

of course

hollow elm
#

how much do you even need to do to handle it? just & 0xFFFFFFFF on every arith operation?

fiery turtle
#

i have a UACPI_PARSE_OP_TRUNCATE_NUMBER

#

thats basically applied to any math operation

hollow elm
#

hm what about a load from a 64-bit field?

fiery turtle
#

its loaded as a buffer

hollow elm
#

ah

fiery turtle
#

if in 32 bit mode

hollow elm
#

not sure what i expected

fiery turtle
#

also on NT if u have a qword immediate its still loaded as a qword

#

even in 32 bit mode

#

so i do that as well

#

and its never truncated unless u do math on it

hollow elm
#

interesting

fiery turtle
#

this affects e.g ToHexString

#

or any compare, greater than etc

hollow elm
#

makes sense

#

i assume it also affects storing to 64-bit fields

fiery turtle
#

yet another acpica incompatibility

#

yup

#

well actually no

#

it would only store the first 4 bytes

#

the rest is zeroed

hollow elm
fiery turtle
#

but i guess its implementation defiend ofc caret

#

i know how nt does it

#

acpica recently fixed ToHexString

#

aka ToHexString(0xF) == "0xF" and not 00000000F

hollow elm
#

god bless

fiery turtle
#

a drop in the bucket but oh well

hollow elm
#

making that one machine where the fw engineer went insane work on linux

fiery turtle
#

lol

#

it was actually from a bug report yeah

#

Some firmware does ToHexString and then Mid to parse the serial number

#

So on linux it was printing out bogus serial

hollow elm
#

ig that use makes sense

fiery turtle
#

yeah

#

not the worst example i can think of

#

Yay large tests pass on CI as well!

#

In both 32-bit and 64-bit builds

#

this bumps the ci up to like 6 minutes on ubuntu

#

but its fine i guess

left orbit
#

@fiery turtle are kernels using uacpi supposed to discover all devices using the uacpi methods? like you can find the ps2 keyboard using acpi, how about pci devices? or is that better done by probing manually

fiery turtle
#

Well you can discover PCI roots and from there match the devices

#

But not all devices are guaranteed to be in the namespace

#

So of course a pci subsystem lives on its own

#

And talks to acpi as needed

#

For pci acpi is more of a nice extension, not a replacement

left orbit
#

i see, i was just wondering since my way of enumerating pci devices is pretty janky and i thought that maybe there is some big brain acpi way to put me out of misery :^)

fiery turtle
#

What sort of jankiness?

left orbit
#

ehhh

#

im not sure if its janky

#

it feels like it

fiery turtle
#

How do you do it?

left orbit
#

i can send the code if you want to take a look, its around 30-40 lines

#

ive written it more than a year ago

fiery turtle
#

I mean sure

#

Lol

left orbit
#

i dont understand the way it works lmao

#

it might be that i just dont remember how exactly pci works anymore, but this isnt very good code either way, it doesnt support mmio which i think is preferred way of doing pci

fiery turtle
#

Looks fairly okay barring some magic numbers

left orbit
#

yeahhh

#

i had to do some msi-x stuff yesterday for xhci so it was a nice reintroduction into some parts of my old codebase

fiery turtle
#

Nice

left orbit
#

i discovered some funny bugs

#

like not having a separate stack for the page fault handler

fiery turtle
#

Are you reviving an abandoned project?

left orbit
#

and now when i add a field to my xhci controller struct i get an kvm error :D

fiery turtle
#

Damn

left orbit
#

ehh im not sure what i wanna do, i wanted to start from scratch

fiery turtle
left orbit
#

with the silly kernel™️

#

but its so much work that im not sure i want to put in

fiery turtle
#

Makes sense

left orbit
#

but zig i just meh, so i guess im working on it for experience so that i can make something better in the future, rather than have the zig kernel be actually good

fiery turtle
#

Why?

#

I thought it was good

left orbit
#

compiler is poo poo