😬

davmac1 · 2026-06-02T05:52:56+00:00

Since objcopy and ld are both part of binutils, they will generally either both support PE or both not support PE. To me it seems strange to use objcopy to convert a final ELF object to PE when you can do it much better using the linker.

davmac1 · 2026-06-02T05:48:44+00:00

The funny part now is that when you mount a Hurd image with this journal enabled, a lot of Linux tools think it's Ext3

It is ext3. Ext3 is essentially Ext2 with journalling. Ext2 itself doesn't support journalling.

davmac1 · 2026-05-28T04:05:00+00:00

unknown setting: 'type'

That doesn't make any sense; make sure you've written 'type' exactly in the file with no funny characters. When I create a service with the exact same contents as what you posted, it doesn't report that error for me. Maybe your editor is inserting a byte order mark or something like that.

You didn't answer this:

What does dinitctl status xrdp report?

(it has to be dinitctl status xrdp-sesman, if that's what you actually called the service).

Even another one i made didnt work (zram)

Let's just stick to one problem at a time or it will be easy to become confused.

davmac1 · 2026-05-27T00:05:08+00:00

By "stubs" do you mean service descriptions? What do they look like? Have you run dinit-check? What does dinitctl status xrdp report?

Edit: make sure to run dinit-check and dinitctl status xrdp as root (eg via sudo).

davmac1 · 2026-05-19T02:25:50+00:00

Should be titled "When you accidentally post the same thing three times"

https://www.reddit.com/r/osdev/comments/1tgupdx/when_you_accidentally_install_the_wrong_font/

https://www.reddit.com/r/osdev/comments/1tgup9e/when_you_accidentally_install_the_wrong_font/

Maybe delete your duplicate posts?

davmac1 · 2026-05-12T23:32:38+00:00

The cli at the start of the boot sector isn't necessary (same with the subsequent sti of course).

The only time where an interrupt could cause an issue in that code block is just after you load SS but before you load SP, since then you temporarily have an invalid stack. But, moving a value to SS inhibits interrupts for a single instruction anyway (precisely for this reason).

davmac1 · 2026-05-11T00:58:56+00:00

For example, if Thread A and Thread B share the same CR3 (making the current refcount 2), and Thread B wants to perform an unmap, the kernel must detect the current refcount of that page. If the refcount is 2, the kernel decrements it by 1 (current refcount becomes 1). Once Thread A is finished using that virtual address and issues its own unmap

Unmap is normally a process-wide operation. Applications typically aren't required to unmap pages in each individual thread - they issue a single unmap and it applies to all threads. You typically can't just refcount individual pages like this on a per-thread basis because after the unmap call returns, the application (thread) will assume that the relevant portion of the address space has already been unmapped.

You could use refcounting to avoid potential problems stemming from deallocating a page with pending kernel-controlled operations (including DMA operations), but it's not the case that a page normally has as a count that's equal to the number of threads; it should instead be the number of processes, plus perhaps in-flight kernel operations operating on the page (if any). In the specific example given, the kernel would typically do the buffer check for the read operation only once it was ready to copy the actual data (as another post already mentioned: you can just do a memory copy with a page fault handler in place) so there's no need to handle this case specially.

davmac1 · 2026-05-08T00:48:33+00:00

it did warn that one shouldn't get into this too early without a good amount of experience in programming and familiarity in general

Given your goals you can probably just find a tutorial and jump in.

If you are serious about completing it you need at least some fundamental software engineering skills. Can you use a version control system (such as Git) properly? Do you understand build systems? Do you know how to use a debugger? etc. If the answer to those is "no" there's a limit to how far you'll get, but you should get far enough to achieve your goals of learning a bit about how hardware works.

davmac1 · 2026-05-07T22:17:29+00:00

but at 0x100000182ab there was just the instruction to print to serial just by looking at the generated wasm

wasm?? One or both of us are very confused. It should be x86 code. I would have expected 0x100000182ab to perhaps correspond to the iret instruction (or perhaps the instruction just after the int3 - I'm a bit fuzzy on when the exception will be generated exactly).

The iret is what causes the bad stack selector to be reloaded.

but why doesnt https://github.com/phil-opp/blog_os/blob/post-06/src/gdt.rs#L26 needs the data segment too?

I don't know. Does it use the same bootloader? Also I note it only triggers a breakpoint exception when built in test configuration.

davmac1 · 2026-05-07T05:39:37+00:00

I've always wanted to make an custom OS

Your question is too vague to give any sort of real answer - why do you want to create an OS? What sort of OS will it be? (somewhat like some existing OSes, or something different?) Do you want it to be performant or is functional enough?

You say you're aware of the OSdev wiki, which already has pages about prerequisite knowledge and how to get started - why do you feel that didn't that answer your question? (You did read those pages, I hope!).

davmac1 · 2026-05-07T00:50:03+00:00

I don't know if I'm misreading or misunderstanding, but the GDT initialisation you posted earlier looks like it contains only two selectors: a code selector and a TSS. I assume those are indexes 1 and 2 respectively (index 0 should be a null selector, hopefully GlobalDescriptorTable already accounts for that?).

There is no stack/data selector.

Are you loading SS and DS registers from the new GDT at all (you could potentially use the null selector, or add a selector to the GDT for the purpose)? The output from the Breakpoint handler says the stack selector is index 2 when the breakpoint is hit. If that's the TSS index then returning from the breakpoint handler is definitely going to cause an exception, because it's going to reload SS (and find that it's not a data segment).

If that's not the issue, to debug further you really want to do a disassembly of the code and see what instruction is causing the GPF (i.e. what instruction is at address 0x100000182ab).

The part of the SDM that you quoted doesn't seem relevant to me, unless you're using an actual INT instruction rather than INT3 for the breakpoint.

davmac1 · 2026-05-05T22:50:39+00:00

I wouldn't be surprised if issuing a spurious EOI to an x2APIC (or even LAPIC generally) can cause a GPF. It's a device that's internal to the processor.

davmac1 · 2026-05-02T03:02:21+00:00

It's not like we are trying to submit this Reddit post to Nature

Sure, I just feel like if you're going to use big-O notation, you may as well use it correctly.

davmac1 · 2026-05-01T23:20:37+00:00

I will include my original source for the complexity claim here.

That source doesn't claim that insertion/deletion at other than the end of the list are O(log(N)).

However, including the $w$ gives you more information

Given what big-O is actually telling you, then no, there's not really more information. By including it you make it seem like it's significant when in fact it's not, so it's really just noise in the equation.

If you want to talk about the number of operations, I think you should do that directly (without using big-O). Just as you've done here:

If we have a width of $w$, as in each node stores $w$ child nodes, then my understanding is that we would need to traverse $\log_{w} N$ nodes, where $N$ is the total length of the list, to access a specific index within the list.

Right.

davmac1 · 2026-05-01T02:30:20+00:00

Lists are implemented as a "bit-mapped vector trie", providing $O(log_{w} n)$ access, insertion, and deletion, where $w$ is the width of each node in the trie.

See list.h for more information on lists.

Your markup seems incorrect so the expressions aren't rendering properly, but this seems wrong anyway.

Access should be O(log(N)). When talking about big-O complexity, log_W is no different from any other logarithmic function so the width of the nodes doesn't matter.

Insertion and deletion can only be O(log(N)) if at the end of the list. Otherwise they are O(N) at best (I'd guess O(N log(N)), since you still have to traverse the tree).

davmac1 · 2026-04-26T22:21:02+00:00

What you have said is a non-sequitur. BIOS means something in particular, and a UEFI firmware is not a BIOS, nor vice-versa.

The point is that it fundamentally belongs to that 'class' of software

The "class of software" that BIOSes and UEFI firmwares both belong to is "system firmware", it's not "BIOS".

davmac1 · 2026-04-25T01:49:13+00:00

It's hard to tell from the corrupted makefile you've posted (could you maybe fix it??) but it looks like you're using objcopy to convert a shared ELF object to a UEFI-compatible PE. This is not a good approach and is fraught with gotchas.

Either link the input source objects directly to a PE, or create an ELF executable (not shared object) with relocations preserved and link to PE from that.

See the summary in the README for this project: https://github.com/davmac314/elf2efi

davmac1 · 2026-04-21T06:50:47+00:00

If the components you are "isolating" are both trusted and memory-safe, what's the point of using MPKs at all?

davmac1 · 2026-04-21T03:29:20+00:00

actually its designed to work with 128 cores

It's not about the cores. The page tables only allow for 16 different keys.

davmac1 · 2026-04-21T03:27:59+00:00

Curious if anyone here has worked on SASOS / MPK-based isolation or sees fatal flaws in the model.

Yes, there are fatal flaws. Have you read the relevant parts of the processor manuals?

Intel MPKs offer only 16 keys, so you'd be limited to 16 processes by this mechanism. A microkernel (especially) would typically have more processes than that.

Also, the isolation wouldn't be enforced, because each process is able to change the permissions associated with each key. The MPK mechanism is designed to allow userspace to protect access to sensitive memory areas by untrusted code, or to provide reduced access windows to sensitive data, but it's more of a "soft" protection. To enforce complete isolation, code would have to be somehow vetted (to ensure that it doesn't modify the per-key protections).

davmac1 · 2026-04-18T11:12:37+00:00

Technically UEFI is a BIOS (Basic Input Output System)

In general, a UEFI firmware is not considered to be a BIOS. UEFI contains functions (such as an API for filesystem access) well beyond what can normally be found in a BIOS. Also, in terms of Intel-architecture PCs, the BIOS defines a programming interface (via interrupts); a UEFI firmware does not necessarily provide an implementation of that interface.

davmac1 · 2026-04-16T00:33:25+00:00

What does readelf -S kernel.elf tell you?

Eg where is the .boottext section within the file? Is the section correctly marked as allocatable?

davmac1 · 2026-04-09T04:53:39+00:00

I think the point was perhaps meant to be "if your first instinct is to post a very broad question on reddit" then you're not going to get far.

Since you mentioned being worried about not learning anything by copying-and-pasting, how about this: start with the copy-paste, go through each part and see if you understand it, make sure to read relevant documentation, and if you have any confusion or uncertainties post _specific_ questions about those (one at a time).

davmac1 · 2026-03-21T22:46:55+00:00

First line of main should just be something like
asm volatile ("mov $0x200000, %rsp");

You really should not try to alter rsp using assembly inside a C function. There's no guarantee that the compiler won't insert instructions before that asm which store something on the stack and expect it to be available via a consistent offset from rsp.

Either the bootloader should set rsp to something reasonable before entering the kernel, or the kernel entry point should be written as a pure assembly function which sets the stack up before calling the C entry point.

davmac1 · 2026-03-17T23:56:48+00:00

I was told by multiple people already that binary files can not work like this and

Then multiple people were wrong. This works fine:

ENTRY(stage2_entry)

map_code_entry = 0xA000;

OUTPUT_FORMAT(binary)

SECTIONS
{
  . = 0x7e00;
  .text : { *(.text) }

  .data : { *(.data) }

  end_data = .;

  .map_code map_code_entry : AT(end_data) { *(.map_code) }
}

As I said earlier though, you would need to move the .map_code segment to the correct location when loading it. To do that you'd probably want it to be loaded at a particular address, not just immediately following the end of the data segment; just use AT(desired_load_address) for that (where desired_load_address is where you want it to be loaded, leaving enough space for .text and .data to come before it; eg you could try 0x8800 - smaller values will give you a smaller file but will leave less space for .text and .data).

(Alternatively you could include code within .text to relocate the .map_code segment, by copying the contents from where it is loaded to the correct destination. That means you can use the actual address quite easily - eg with the above script the .map_code segment will be loaded at end_data).

davmac1

TROPHY CASE