Correction: I'm speculating about the reason; I don't know the developers' intent. The SWAPGS-specific article is at <https://en.wikipedia.org/wiki/SWAPGS_(security_vulnerability)>

jumped in a little too early, 
Story

On September 29, 2026 6:51:48 AM EDT, Story <story@unhelpful.observer> wrote:
>Hi,
>Letting processes set their own GS.base would expose the classic SWAPGS speculative side-channel class of bugs (CVE-2019-1125 and friends). Keeping GS under exclusive kernel control removes that attack surface and keeps the entry/exit paths simple. Here is a Wikipedia article. <https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)>
>I'm not an expert, I'm still reading the man pages, but I do know there is no plan to add a syscall for it.
>Thanks,
>Story
>
>
>On September 29, 2026 5:32:51 AM EDT, Neth Iafin <NethIafin-obsd@proton.me> wrote:
>>Hi OpenBSD,
>>
>>I was wondering why OpenBSD has no ability to set %gs in userland?
>>
>>Is this to avoid swapgs vulnerabilities? Something else?
>>I understand that supporting wine is probably below 0 on the priority list for OpenBSD, but I wonder about the reasoning behind %gs being locked to kernel.
>>I assume there is no chance that setting %gs will ever come back as a syscall?
>>
>>Thanks,
>>Neth