<klange>
Andrew: Are you sending the correct line endings for an HTTP request?
GeDaMo has joined #osdev
the_lanetly_052_ has joined #osdev
jafarlihi has joined #osdev
<stephe>
if i have a GDT with 3 descriptors, it should have size 24 bytes right? but then you put 23 in the gdt descriptor size field, is that correct?
<Mutabah>
Yes.
<Mutabah>
The field name is "limit", which is size minus 1
<stephe>
that's what i thought, i see a lot of examples where its being set to 24 though, which is weird
nyah has joined #osdev
<klange>
gdt can have an extra byte, as a treat [do not do this]
<mrvn>
it's stupid that the gdt size isn't in multiple of slots.
<Andrew>
That's ... weird
gog` has joined #osdev
<Andrew>
Whatever, it's not too important to me
<Andrew>
./b 25
<Mutabah>
Eh, I'd assume it's using similar logic/circuitry to the segments themselves, which have a limit instead of size so they can have a size that includes the largest address
<mrvn>
otherwise the largest GDT would have size 0 and they would have to syntesize the overflow 1 bit internally.
<mrvn>
Saves 1 bit in the opcode. But using the number of slots would have saved 2 more.
<mrvn>
s/opcode/descriptor.
graphitemaster has quit [Ping timeout: 248 seconds]
graphitemaster has joined #osdev
Burgundy has joined #osdev
bliminse has quit [Ping timeout: 256 seconds]
bliminse has joined #osdev
jafarlihi has quit [Quit: WeeChat 3.5]
pretty_dumm_guy has joined #osdev
<stephe>
so if im understanding this right, i long jump to 0x8:protected_mode to set cs to 0x8 so the code uses the code descriptor, and then the other registers, ds, es, fs, ss, etc should be set to 0x10 so they use the data descriptor?
<\Test_User>
as long as your second entry in the gdt is for code and the 3rd is for data, yes
<stephe>
yea that's right... right now i have both descriptors set up with base 0 and limit 0xffff, is it possible to just have 1 descriptor and use it for both the code and data? since they are both overlapping i dont see the point really?
<stephe>
i guess if they were separate areas of memory then you wouldnt want the data to be executable
<\Test_User>
you cannot, they are two different types, for the code descriptor one specific flag is if it's readable, for data that same flag means if it is writable
<stephe>
ahh
<\Test_User>
also you may want to ensure you're using the full limit, there's a 2nd section of the limit (4 bits) for it in the gdt, along with a flag for granularity (in units of 1 byte if not set, 4k if set)
<stephe>
ahh
Vercas has quit [Ping timeout: 240 seconds]
dennis95 has joined #osdev
Vercas has joined #osdev
sympt has quit [Read error: Connection reset by peer]
sympt has joined #osdev
<stephe>
how does the size flag work, apparently you can have a 16 bit segment and a 32 bit segment, what would that be used for?
<Mutabah>
iirc it changes the default address size for accesses
<stephe>
hmmm
sheb has joined #osdev
eroux has quit [Ping timeout: 260 seconds]
gog` has quit [Ping timeout: 246 seconds]
<mrvn>
use 64bit mode, base and limit are ignored
xenos1984 has quit [Read error: Connection reset by peer]
<mrvn>
in 64bit mode you still might want a 32bit CS/DS but 16bit is certainly dead.
<\Test_User>
in 64-bit you also need to setup paging
<mrvn>
you want a kernel without virtual memory?
<\Test_User>
definitely doable, and probably simpler to start with and setup later
eroux has joined #osdev
<mrvn>
it's easy to set up a identity mapping if you really want no virtual memory
<Andrew>
I personally feel like not having virtual memory so that programs could just pass things around (IPC-wise) as pointers
<Andrew>
Though, memory protection would be *a bit* harder[tm]
<mrvn>
Andrew: you can have a global address space and still have virtual memory.
<\Test_User>
can't you use the gdt to protect ram... until you go to 64-bit mode where it becomes obsolete
<mrvn>
and you definetly want 64bit for that. 32bit / 2GB gets kind of crowded if all programs share it.
<Andrew>
mrvn: Having virtual memory already makes things more complicated, and I want better system integration, meh
<\Test_User>
but also yes, you *can* have the kernel intervene and interpret the pointers through vertual memory
<\Test_User>
mrvn: you've got 4GB in 32-bit mode, not 2GB
<Andrew>
x86 sucks - Going to MMIX *sometime*
<mrvn>
\Test_User: you can if you give every process it's own GDT/LDT entry.
<\Test_User>
ye
<mrvn>
\Test_User: not if you split between kernel space and user space
<\Test_User>
why do you need to divide it in half to split it though
<mrvn>
no reason
<\Test_User>
surely you can split it at e.g. 3GB userspace and 1GB kernel
<mrvn>
if you don't do virtual memory you wouldn't split.
xenos1984 has joined #osdev
<zid>
You can, and linux does
<zid>
and by does I mean, did, 30 years ago
<zid>
when 32bit was relevent
<Andrew>
I have 32-bit machines
<mrvn>
recycle
<Andrew>
I like them
<Andrew>
And use them
<mrvn>
update and save power and money
<Andrew>
mrvn: Works fast enough for all my purposes, doesn't use much power either
<Andrew>
Also most modern computers have nonfree stuff
<Andrew>
And are harder to libre/os-boot
<zid>
all computers from every era are non-free to begin with
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
<Andrew>
Indeed, but the older ones are better
gog` has joined #osdev
<Andrew>
For example, no management engine or platform processor at all
<zid>
less features is less features, not more free
<Andrew>
Yes I know AMD exists, but still my current 32-bit machine totally works for me
<zid>
I like wake on lan, kvm switching, etc
<zid>
I've *never* controlled the firmware on my PC, ever, in any era, and neither has anybody else
<zid>
that you happen to *know* the name of the firmware image now changes nothing
<\Test_User>
zid: when was the last time you needed to manage your laptop's bios config with ssh
<zid>
That wasn't the question
<Andrew>
All of these are free software allowing for even more flexibility
<Andrew>
Than what ME could provide
<\Test_User>
but the ME is required on *every* intel CPU built nowadays
<zid>
He said "what stuff can my laptop not do", when I said ME adds features
<Andrew>
AND it's free software
<\Test_User>
true
<Andrew>
zid: I can *easily* implement that in linuxboot
<zid>
go for it, no you can't
<zid>
You need the ME
<\Test_User>
you may want to look at libreboot before saying he can't
<zid>
It's physically impossible not to use the ME
<\Test_User>
may require the system to be running, sure
<Andrew>
zid: I currently don't have a BIOS, but sure, I could change it
<zid>
Nobody asked you to change anything, you were asked to ssh into your motherboard
terminalpusher has joined #osdev
<Andrew>
zid: I am implementing this SSHing thing because it's not built in as the developers didn't see a need for it; I'm demonstrating that implementing and using this (and more features) is possible with (partially) free firmware with free BIOS
<zid>
Great, but you can't, it's not physically possible.
<\Test_User>
Andrew: "if it isn't running then you can't"
<Andrew>
zid: You bet :)
<Andrew>
Do you know what Libreboot it?
<Andrew>
*is?
<mrvn>
zid: I can ssh into my ARM
<zid>
You'd need some kind of processor to run it on
<zid>
some kind of.. management processor
<\Test_User>
not saying it's smth you want, just saying you can't do it without this
<Andrew>
zid: I have a CPU
<zid>
That's not what was asked.
<\Test_User>
Andrew: it needs to be running
<zid>
I didn't say install linux
<zid>
and ssh into your computer
<zid>
I said ssh into your *motherboard*
<Andrew>
zid: Linux *is* my firmware/BIOS, similar to how Minix is used in Intel ME
<mrvn>
zid: upgrade your "motherboard" to fix the security bugs
<zid>
It is not firmware.
<Andrew>
Then what do you call the software running in the ME?
<mrvn>
don't kid yourself. ssh isn't done in hardware
<zid>
Firmware, you said you don't want ME and can do everything without it.
Vercas has quit [Quit: Ping timeout (120 seconds)]
<Andrew>
<zid> It is not firmware.
<zid>
so either you've sneakily decided to use the ME purposefully to try win an argument that only you care about
<Andrew>
What's "It"?
<zid>
or no, that's exactly what you're doing
Vercas has joined #osdev
<zid>
you just refuse to admit that the ME does *anything*
<\Test_User>
what's the big difference between running ME with it and leaving your main CPU on a low power state for everything
<Andrew>
I admit that ME does things :)
<Andrew>
I just say that free things can do it, and allow for better flexibility and freedom
<zid>
\Test_User: tbh, I 've reflashed my mobo like 10 times without the cpu even installed, super glad I could do that
<Andrew>
Why avoid the CPU?
<\Test_User>
zid: the ME is a CPU
<psykose>
i would have simply installed a cpu
<zid>
you mean, buy a second, older gen cpu
<zid>
so that you can run DOS, to run the flasher util
<\Test_User>
unless you can run your motherboard on the ME, it's kinda pointless to do things without a CPU attached
<zid>
or I could just put a usb stick into my mobo and press a button on it
<zid>
and the ME will walk the fs, look for bios images, and update it
<Andrew>
zid: And you don't need to use DOS of tht stuff if you use Linuxboot or Libreboot or osboot or coreboot :)
<mrvn>
zid: I rather just copy the file to the SD card
<zid>
Andrew: on what cpu?
<zid>
The one we just discussed *is not in the same room*?
<Andrew>
And I have Linux, which is GPLv2 free software that does it, rather than something I am incapable and cannot legally view; Here we'r comparing your preferred situation and my preferred situation I suppos?
<Andrew>
s/./e?/
<Andrew>
s/\./.$/
<psykose>
i think you misunderstood his point
<zid>
Yes, that's precisely what's happening, I spent the last 30 minutes arguing closed software is worse. It 100% wasn't you arguing that ME does nothing.
<zid>
err better*
<Andrew>
You're arguing that closed software is better?
wand has quit [Ping timeout: 240 seconds]
<zid>
Clearly, it's easier to just agree with you
<mrvn>
software is never closed. Someone will crack it open quickly.
<Andrew>
In and of itself of the closed nature or because you think the ME can do important things that I wouldn't be able to?
<zid>
Having a use-case that you don't is not tolerated
<mrvn>
back box security is a joke.
<Andrew>
mrvn: Totally legal
<Andrew>
mrvn: Agreed with that
<mrvn>
Andrew: hackers don't care about legal
<Andrew>
zid: "that you don't" not sure what that means
<Andrew>
mrvn: Users care, and using Libreboot you get the features having it still legal
<psykose>
the usecase in this specific instance is he bought a motherboard and cpu that were not compatible at the current motherboard bios revision
<psykose>
but the motherboard has a feature to update itself.. powered by the me
<Andrew>
Ohh I get it now
<psykose>
without it, the new cpu wouldn't work at all, you would need an old cpu to update to new bios first
<psykose>
it's a thing on a bunch of the am4 amd boards because you need the new bios to run newer zen cpus, but you don't know what bios revision the boards really ship with
<\Test_User>
I mean, the ME is the old CPU used to update to the new BIOS
<psykose>
sure, if you want to see it that way
<zid>
You're thinking about it very weirdly
<zid>
the mobo is just a computer in itself
<zid>
This is like the ECU on a car or something
<psykose>
indeed so
<zid>
the point of the car isn't the ecu, but you're pretty glad you have one
<Andrew>
That is indeed one case where the ME would help where lb/ob/cb cannot - it boils down to what you think is more important, free sw/hw or using the thing on the motherboard (that has almost completely nonfre software)
<Andrew>
leah, et al are trying to get osboot/libreboot working with more performant CPUs which I'm following
<zid>
these anti-ECU people are weird, I like the extra engine management features and wouldn't cripple my car just because honda won't mail me the source
<Andrew>
I would feel otherwise, difference in ideology
<mrvn>
what does the ME do when you install libreboot?
<zid>
Some people pine for the "good ol days" where cars didn't have their own electronics, but it just means you miss out on stuff
wand has joined #osdev
<mrvn>
when the atom bomb drops so you will you
<Andrew>
mrvn: Libreboot uses me-cleaner that disables the ME if it's present
<psykose>
i pine for the good old days where the cars didn't exist
<zid>
and none of it is 'free' anyway, you couldn't replicate a single part of it without their gigs of proprietary stuff
<zid>
at least re computers
<Andrew>
LB isn't compatible with boards where Me cannot be disabled, in those cases use osboot which cleans it as mych as possible
<zid>
It isn't compatible with boards, is easier to say
<\Test_User>
zid: there is nothing about proprietary that magically cannot be done at all with libre software
<zid>
\Test_User: of course not, but reality is real
<zid>
so good luck convincing asus and intel to tell you know how to operate an x399 mobo
<mrvn>
\Test_User: hide NSA backdoors the russians can use?
<Andrew>
zid: Yes, lb ports are pre modern ME
<\Test_User>
yes, currently, most hardware is non-free
<Andrew>
zid: Not caring about Intel :) I care about libresilicon and sam zeloof's work
<\Test_User>
mrvn: lol, didn't mean it like that but yes
<\Test_User>
zid: doesn't mean no one other than asus or intel can make motherboards
<zid>
okay?
<Andrew>
zid: mrvn: May I have permission to copy this conversation' logs to leah?
<zid>
Why do you keep saying totally obvious things in a way that looks like you're replying to me having claimed them as true
<zid>
No
<Andrew>
Ok
<\Test_User>
> zid | so good luck convincing asus and intel to tell you know how to operate an x399 mobo
<\Test_User>
point is you don't need them to tell you, get a different motherboard or find someone who can make a libre one
<Andrew>
zid: Why convince them or get them tell you?
<zid>
Okay, great, but again, not responding to what I said at all
<zid>
None of this conversation has been about designing and manufacturing motherboards
<Andrew>
zid: Explain what you mean by reality is real
<zid>
so I've weirdly not responded to any such claims with "no you can't, only intel can m ake mobos"
<Andrew>
s/motherboards/libre hardware/?
<zid>
so I responded to "zid: there is nothing about proprietary that magically cannot be done at all with libre software" instead, by saying "yes you can, but good luck, because as *you just noted*, it's proprietary"
<zid>
Sorry for replying to what was said, not a to a conversation nobody was having
<Andrew>
Uh, what do you mean by "reality is real"
<zid>
You can claim you could just make a mobo with your own software on it just fine
<zid>
but it doesn't let you escape the realities of reality, that mobos are complicated $500 pieces of kit, that you'd have to charge $20000 to recreate in a small volume, and by the time you did you'd be 10 years out of date
<mrvn>
i am. geist is. lots of people are
<zid>
and is thus, not really a valid "ah yes but"
<zid>
it's just goalpost moving
<\Test_User>
"10 years out of date", which is why you need to think ahead rather than taking a current one and using that
<Andrew>
My point is that I'm optimistic that it could catch up, by some day, too
<zid>
think ahead.. to standards that don't exist?
<Andrew>
And yes, x86 also sucks
<zid>
You're going to route pci-e 7.0 electrically how? That's what mobo designers do.
<Andrew>
zid: create standards
<zid>
Wow
<Andrew>
PCIe, lmao that sucks
<mrvn>
making an ARM mainboard is pretty much point and click nowadays and far below $20000
<zid>
So your solution to the pcie group moving faster than you can
<zid>
is to *compete with them*
<zid>
now I know you're either insane or trolling, or both
<zid>
"Just replace a trillion dollars in market cap worth of companies"
<Andrew>
I mean, competition is the way to break monopolies, really
<mrvn>
Andrew: well, you have to buy a license and a millions of dollar chip fabricator.
<\Test_User>
buy a *license* to make a motherboard/etc?
<\Test_User>
what
<mrvn>
no, just for the cpu to put on the MB
<Andrew>
mrvn: You're missing out on things like libresilicon and sam zeloof, I still have a ton of homework so i'ma afk for a while, but I don't know what you mean by the license
<Andrew>
mrvn: Miswrote, the CPU is also in the field of remaking
<mrvn>
Andrew: all you need to make a MB is kicat.
<Andrew>
RISC-V iscurrently the most feasible
<Andrew>
Though, its instructions still seem a bit dirty technical wise and a practical MMIX speclementation would be nice
<Andrew>
zid: Same as how all democratic revolutions did back then; the government (those companies) is (are) powerful (rich), doesn't exactly prevent people from competing and replacing
<Andrew>
I will summarize and publish what zig said, removing personal identification, time, etc
<zid>
I thought you were about freedom not piracy
<\Test_User>
where did piracy come in there
<zid>
He asked for permission to publish what I said and I said no
<zid>
and he just announced he's doing it anyway
<Andrew>
Paraphrasing
<Andrew>
Legal in my juristiction
<Andrew>
If you want attribution, sure
<\Test_User>
ah
<zid>
I want editorial control not attribution
<zid>
I don't trust you
<zid>
especially given you didn't seem to understand anything I said
<zid>
and kept aruging against reality
<Andrew>
Okay, then no attribution - this distribution is legal under my juristiction anyway
<\Test_User>
Andrew: "legal" doesn't always mean "good idea"
<Andrew>
\Test_User: I find strong reasons for me to do so
<zid>
is it against libre's tos? it was against freenode's
<kingoffrance>
it never does. it means letter, not idea/spirit/"Morals" etc.. it may occasionally overlap.
<kingoffrance>
:)
<Andrew>
kingoffrance: Correct
dude12312414 has joined #osdev
<kingoffrance>
dont cross the streams :) that would be bad
<Andrew>
I don't see it contridicting to Libera policy
<mrvn>
kingoffrance: now you violated the IP of Ghostbusters.
bauen1 has quit [Ping timeout: 244 seconds]
dude12312414 has quit [Remote host closed the connection]
jafarlihi has joined #osdev
the_lanetly_052 has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 258 seconds]
terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #osdev
vdamewood has joined #osdev
jafarlihi has quit [Ping timeout: 255 seconds]
terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #osdev
frkzoid has quit [Ping timeout: 255 seconds]
MiningMarsh has quit [Ping timeout: 255 seconds]
diamondbond has joined #osdev
terminalpusher has quit [Remote host closed the connection]
_73 has joined #osdev
<_73>
Does every single thread in the linux kernel maintain two seperate stacks, one for when the processor runs in user mode and one for running in kernel mode?
<bslsk05>
www.kernel.org: 6. Kernel Stacks — The Linux Kernel documentation
<zid>
"Like all other architectures, x86_64 has a kernel stack for every active thread."
<zid>
and one per IRQ per core apparently
<zid>
That'll be the one in the TSS RSP0 presumably
<_73>
Ok. I dont understand why every single thread needs a kernel stack though. Why cant the kernel just have one stack that it uses for executing syscalls?
<zid>
blocking syscalls, are one reason
<zid>
so one thread is stuck in read() or whatever, with a bunch of args on its stack etc, and will eventually wake up and start running again
bauen1 has joined #osdev
<zid>
another thread is going to struggle to re-use that stack without a lot of accounting details about which bits of the stack are owned and active by which thread
MiningMarsh has joined #osdev
<zid>
and if the read()'r wakes up.. it can't push anything else it's going to shit on the other thread's data
<zid>
It's fine if nothing ever blocks or pre-empts anything else I think though
<_73>
Ahh so in the read() case the kernel tells the disk to read, and while that is happening can execute other syscalls. If there was only one stack it would have to figure out how to save the process state for the read call somewhere so it can be restored when the disk interrupts the kernel to tell its done.
<zid>
and that 'save it somewhere' is called.. a per thread regsave area, aka a kernel stack
<zid>
:P
<_73>
Got it, now I understand.
<zid>
your terminology a second ago worries me though
gog has quit [Ping timeout: 260 seconds]
<zid>
"can execute other syscalls" makes it sound like you think that there is only one 'the kernel'
Vercas has quit [Remote host closed the connection]
<_73>
I do view it as one 'the kernel'
<zid>
Every thread has its own entirely isolated private kernel mapped into its address space, effectively.
<zid>
(or rather, process)
<zid>
there isn't a "the" kernel which runs processes
<zid>
there are n processes, which are each some ring3 and some ring0 code in a bundle, which switch being being active
<zid>
s/being //
Vercas has joined #osdev
<zid>
and hopefully the ring0 code doesn't let the ring3 code jump to it in a way that it doesn't want
<_73>
zid: Why does every thread need a private kernel instead of every process needing one? Why can't threads in the same process share a kernel?
<zid>
they do, I corrected myself sorry
<_73>
Oh ok
bauen1 has quit [Ping timeout: 272 seconds]
<zid>
I find that a much cleaner way to look at it, than trying to wrap your head around some magic kernel mode
bauen1 has joined #osdev
<zid>
Your process just has some code mapped into it that expects to run at cpl=0, and there's a special jump instruction to do that, it's still your process running that code
<zid>
There's no "the kernel" which is running your process
<_73>
what is cpl=0 ?
<zid>
ring 0
<_73>
I see
<_73>
It seems that it would cost a lot of memory for every process to have its own kernel
<zid>
it's basically free
<zid>
the physical memory is shared thanks to virtual memory
<j`ey>
_73: it's just mapped the kernel, it's not a different copy
<zid>
and the kernel is a couple of megs, which is a couple of 2MB page table entries
<_73>
Ohh of course I forgot to consider VM
<zid>
so a pml4 which you have anyway, and an extra pdpt and pde
<zid>
so probably 8k to get the kernel .text mapped into a process
<zid>
like, bare minimum, I'm sure linux has a whole bootload of complex structures it needs to keep mapped at all times though
<zid>
It'd be somehwat interesting to dump a snapshot of a linux process and see what's in it tbh
<_73>
How can I do that?
<zid>
qemu?
<zid>
I want a cool visualization tool for this now
<zid>
work on that for me
diamondbond has quit [Ping timeout: 276 seconds]
<GeDaMo>
Wouldn't you just keep the whole kernel mapped in all the time?
<zid>
yes
<zid>
but linux is kinda complex, so presumably it has a bunch of complex mappings, sadly
<_73>
Is the FreeBSD kernel as complex?
<zid>
mostly
<zid>
it still does modern OSy things
<_73>
I see. I am reading "The design and implementation of the FreeBSD kernel". It is quite good.
<zid>
sounds nice
_73 has left #osdev [ERC 5.4 (IRC client for GNU Emacs 28.1)]
_73 has joined #osdev
_73 has quit [Client Quit]
_73 has joined #osdev
_73 has quit [Client Quit]
_73 has joined #osdev
_73 has quit [Client Quit]
_73 has joined #osdev
_73 has quit [Client Quit]
_73 has joined #osdev
heat has joined #osdev
<heat>
linux x86_64 doesn't have "complex" mappings
<heat>
the kernel mappings are just a carbon copy of each other in every address space
<\Test_User>
> 0000000000000000 | 0 | 00007fffffffffff | 128 TB | user-space virtual memory, different per mm
<\Test_User>
so nullptr is mapped to userspace
<heat>
no
eck is now known as nullptr
<heat>
theoretically you can map it if you set your personality(2) correctly
<heat>
MMAP_PAGE_ZERO maps 0x0 as a read-only zero page (like SVR4)
<\Test_User>
interesting
<heat>
yes
<heat>
it's all weird SVR4 compat code
<heat>
wouldn't be surprised if it doesn't work anymore
<heat>
anyway, if you break it down, the memory map for x86_64 linux kernels is relatively simple
<\Test_User>
agreed
<zid>
vmalloc space is lazily synchronized into the different PML4/PML5 pages of
<zid>
the processes using the page fault handler, with init_top_pgt as
<zid>
reference.
<zid>
That probably helps
<heat>
how is that complicated?
<zid>
how is it trivial
Likorn has joined #osdev
<heat>
it's not trivial but it's in the middle of trivial and complex
<zid>
truncating is for people who think shifts are rad
<heat>
it's a relatively standard solution to lazily sync the top page table
<sbalmos>
horribly brain-dense question, scrolling back and reading... say the kernel itself is a few megs, and some space for kernel stack per-thread... is it because the kernel has to map in user-space memory in order to copy back and forth that our VMM layout has the upper 1-2 *gigs* of address space reserved to the kernel?
mahmutov has joined #osdev
<heat>
sbalmos, yes
<zid>
all your device memory also needs to be in the kernel half unless your drivers are in a different address space
<heat>
the kernel also needs to allocate memory
<zid>
which doesn't help
Likorn_ has joined #osdev
<heat>
having the kernel in its own address space would work but it would be slow
<heat>
(would work if you could have a miny kernel that just switched address spaces)
<sbalmos>
heat: I'm coming from the starting point of microkernel design, so drivers etc would be in a different address space anyway
<zid>
well, make it small and then make it bigger every time it isn't big enough :P
<heat>
funnily enough, you can use something like this with PTI
<heat>
s/miny/mini/g
<heat>
PTI manages to make it fast because it uses ASID/PCID when available, which lets it avoid flushing the TLB every time it does the user <-> kernel transition
<sbalmos>
just always bugged me at some visceral WTF level that each process's address space had over half of it reserved to the kernel, potentially many multi-gigs' worth
<heat>
it's wayyyyy faster and more practical
<zid>
well, feel free to use a bounce I guess
<zid>
given spectre and all that it might not be that much slower
<sbalmos>
¯\_(ツ)_/¯
<heat>
copy_from_user and copy_to_user will be super slow
<heat>
(if you don't reserve the top address space)
<heat>
right now it's an optimistic memcpy with a fallback exception handler that lets it -EFAULT
<heat>
if you don't reserve the top of the address space, user and kernel addresses can collide, so that goes out the window
Likorn has quit [Ping timeout: 260 seconds]
<sbalmos>
then again I should probably just get over it. Look at the Linux MM layout like you linked. Upper-half is /petabytes/ of address space. So it realistically doesn't matter
<zid>
128TB in practice, but yea
<sbalmos>
yeah sorry, was looking at the 5-level section
<heat>
realistically, if you're running an address space hungry app in 32-bit, stahp it
<sbalmos>
4-level is 128TB. Still...
<sbalmos>
yeah yeah yeah. This is the "shut up and get over it" point
<heat>
oh yeah I forgot
<heat>
32-bit apps on top of 64-bit kernels *can* use the top 1GB
<sbalmos>
interesting to see how much address space is "unused hole"
<heat>
i would assume that the holes are there so the next address space region can be aligned to a PDPT entry address boundary
dennis95 has quit [Quit: Leaving]
freakazoid333 has joined #osdev
<clever>
heat: what about the specter era exploit mitigation, where you swap the paging tables upon entry to kernel space, could that allow a 32bit userland to use nearly the full 4gig on a 32bit kernel?
<clever>
baring just a 1 or 2 page handler to swap over
<mjg_>
that's meltdown
<mjg_>
and ye, that's what freebsd is doing
<mjg_>
and i suspect linux as well
<clever>
but would that then allow you to use the upper 1gig in a 32bit kernel?
<zid>
yea it was mentioned
<clever>
since its not actually mapped
<zid>
the problem was copy_from_user etc
<mjg_>
yes, that's the "benefit"
<zid>
you can't have a huge kernel *and* a huge userspace mapped
<clever>
ah, yeah, copy_from_user would need to know if its a kernel addr or a userland upper 1gig addr
<mjg_>
albeit it's probably a bad idea to add it
<clever>
so you have to be more strict, about copy_from_user only ever being given userland pointers
<zid>
you'd need bounce buffers or clever remappings and a copy or whatever
diamondbond has joined #osdev
<heat>
right, every user <-> kernel access would become a lot slower
<clever>
it would need to ensure the userland page is mapped somewhere
<heat>
clever would need clever remappings hehehehehehehe
<clever>
which you get for free, from a 3g/1gig split
<zid>
well if I needed them they'd be zid remappings
<mjg_>
it's too risky to think real world 32 bit userspace does not have dependencies of addresses always being below 3G though
<mjg_>
i remember real world code breaking on a set up where there was 1G for the user and 3G for the kernel
<clever>
at least in the rpi firmware api's, it expects userland pointers to fit within a 32bit int
<heat>
above 3GB
<clever>
so the limit is 4g, not 3g
<mjg_>
heat: oh? and that still works?
<heat>
oh god the stockholm syndrome is kicking in again
<heat>
mjg_, afaik yeah
<clever>
heat: lol
<clever>
just giving an example of some limits i know of
<mjg_>
solid
<heat>
you could've said like
<heat>
most older DMA interfaces
<clever>
in the past, i have ran into issues just LINKING firefox on a 32bit kernel
<heat>
let me guess, LTO?
<clever>
heat: but this isnt anything to do with dma, userland pointers are being passed to the firmware as opaque tokens, that just get bounced back to userland in a reply
<heat>
the fuck
<clever>
so the userland can find its own state and deal with the reply properly
<clever>
a lot of api's do similar, like the arg to pthread_create
<clever>
in this case, its just bouncing the pointer off a remote core
<clever>
mqtt does similar, but expects that token to be treated more like a sequence#
diamondbond has quit [Ping timeout: 276 seconds]
<clever>
if the remote core was potentially hostile, it would be far worse, you would be expecting an attacker to not modify a pointer your going to use
<mjg_>
heat: erm, i meant old code recompiled to 64 bit and crashing due to truncating addresses
<mjg_>
heat: sorry :)
<heat>
brilliant naming
<heat>
mjg_, oh yeah for sure
<clever>
heat: ah, close enough, still suits mostly the same purpose
<heat>
i've seen plenty of newbs get into trouble with malloc and implicit decls
<heat>
or anything and implicit decls, really
<heat>
if every argument is an int that will blow up on any pointer
<mjg_>
loloprogs crashing like this were the standard ticket in red hat support for years
<heat>
C is a crap language
<heat>
reject language become monke
<Andrew>
How is C a crap language?
<Andrew>
I mean, yes it doesn't give you interger overflow detection as you could easily do in assembly or Zig but that's about it
<GeDaMo>
Well, there's that whole 'buffer overflow' thing :P
<\Test_User>
buffer overflow is purely the programmer's fault
<heat>
buffer overflows, memory leaks, this whole implicit declaration footgun pointed at your feet
miezekatze has joined #osdev
<heat>
\Test_User, right. the language assumes competency. bad assumption
<GeDaMo>
Yeah, programmers are idiots :P
<Andrew>
GeDaMo: You could get that with any unsafe language that has implicit declarations and a faulty programmer
<Andrew>
"faulty programmer" xD
<\Test_User>
XD
<psykose>
programmers fault indeed. except if we decided that 'faulty programmers' shouldnt write code, we would not have any software
<Andrew>
Zig seems to not have implicit declarations
<Andrew>
psykose: Of course, lol
<psykose>
every piece of software you've ever touched has had a buffer overflow in it somewhere at some point :p
<GeDaMo>
Probably still does :|
<Andrew>
psykose: I have a simple program under Linux:
<Andrew>
global _start
<Andrew>
section .text
<psykose>
here comes the hello world meme
<Andrew>
yup
<Andrew>
exactly
<Andrew>
and how could you buffer overflow it...
<Andrew>
_start:
<Andrew>
(it's linux 32-bit so)
<heat>
you can stop
<\Test_User>
still though, languages that do that automatically are generally more inefficient
<Andrew>
\Test_User: You mean languages that check?
<Andrew>
Or languages that have explicit declarations?
<\Test_User>
Andrew: languages that assume incompetent programmers
<Andrew>
Ah
<heat>
no
<heat>
C++ is not measurably less efficient
<heat>
so isn't rust
<\Test_User>
C++ is terrible for enough other reason; and I did say "generally"
<heat>
it might be a tiny tiny bit. but it's not measurable
<Andrew>
s/inefficient/either inefficent or insane/
<heat>
ok but it doesn't fail in the basic functions of a fucking language
<GeDaMo>
Some inefficiency is preferable to a massive security hole
<Andrew>
heat: class
<heat>
struct
<j`ey>
enum
<Andrew>
struct is better
<\Test_User>
GeDaMo: that's where it requires a good programmer
<Andrew>
C enum is, bruh
<Andrew>
GeDaMo: True, but leave those to checkers
<heat>
\Test_User, name a good programmer
<Andrew>
Well, it is harder to prove-correct/verify an imperative program
* \Test_User
lacks names of enough programmers to do that
<Andrew>
"Donald Knuth" - nah, still not a good enough programmer
<GeDaMo>
Fabrice Bellard
<Andrew>
Yeltsa Kcir (jk)
<\Test_User>
but so far I have yet to make such a problem with C, so it's not all that hard to ensure you free everything you malloc, check malloc's return value, etc
<GeDaMo>
How do you know you haven't made one?
<\Test_User>
buffer overflow can be avoided by proper testing
<heat>
the fact that immediately after you enable asan/ubsan (and optionally start fuzzing) you discover a crap ton of bugs makes you think that there's no such thing as a "good programmer"
<Andrew>
\Test_User: s/testing/verification which is generally hard for imperative programs/
<Andrew>
Even when
<\Test_User>
...proper testing and proper thought when writing*
jafarlihi has quit [Ping timeout: 276 seconds]
<heat>
right
<GeDaMo>
"Program testing can be used to show the presence of bugs, but never to show their absence!" -- Dijkstra
<heat>
ladies and gentlemen we've fixed security vulnerabilities
<heat>
just think
<Andrew>
... * even when you assume that the cpu and compiler works perfectly
<heat>
that's the solution
<Andrew>
GeDaMo: Verification does, though
<Andrew>
Formal proof
<\Test_User>
Andrew: and that's why I prefer assembly
<_73>
Ive been messing around with ATS which gives you the same control as C/C++ but with total safety due to dependent types. The downside is nobody uses it and its hard to learn. http://www.ats-lang.org/
<Andrew>
\Test_User: Still gotta deal with the CPU
<Andrew>
Though now you got to deal with Kurt Godel
<\Test_User>
yes the CPU isn't my fault though and there's nothing I can do about that
<GeDaMo>
"Beware of this code. I have only proved it correct, not tested it." -- Knuth
<Andrew>
xD
diamondbond has joined #osdev
<Andrew>
Be aware of Kurt Godel who will damage your brain with "a consistent system of mathematics with peano arithmetic cannot prove all true statements within utself"
<Andrew>
*itself
<Andrew>
And "A consistent shstem of mathematics with peano arithmetic cannot prove its own consistency"
<Andrew>
And now you can't verify programs properly
<Andrew>
Because what if you're dealing with an inconsistent proof system
<\Test_User>
then don't use the CPU to prove itself, use your brain and the transistors behind it[tm]
<heat>
oh sure because that always works
<\Test_User>
yes that was intended as a joke
<\Test_User>
anyways, back to it - "if you cannot make bug-free code, neither can the person who made the compiler that tries to make bug-free code for you"
<heat>
well you seem to explicitly defend that C is a good language
<\Test_User>
there's some things I find lacking in C, but overall yes
<\Test_User>
already mentioned by andrew, overflow detection is the main thing I find lacking
<heat>
do you not find the complete lack of memory safety lacking?
<\Test_User>
though apparently there are patches to get gcc to work with that
<\Test_User>
nope, I like to control what my programs do when
<Andrew>
heat: Haxuser finds lack of memory safety completely okay
<\Test_User>
*personally-made memory safety
<\Test_User>
not total lack of
<heat>
you don't lose control with memory safety
<Andrew>
If it's the compiler checking at compile time, or the assembler doing some extra work without effecting its output I suppose hax is okay with it
<\Test_User>
s/hax/Test_User/g, do be sure to use my nick when there is no context of the other to confuse everyone
<Andrew>
k
<\Test_User>
*to not confuse
* Andrew
haxes \Test_User
<\Test_User>
but yes sure, if the compiler can check that I didn't leave any memory leaks then I'm fine with that
<Andrew>
* or assembler
<Andrew>
or nah
<Andrew>
probably an external program should do it
<\Test_User>
assembler does what I tell it no matter what
<Andrew>
not the assembler itself
<\Test_User>
yes
<Andrew>
but it shouldn't alter output or stuff
<\Test_User>
*as long as it is valid, not no matter what
<Andrew>
Well.. it's a bit hard to validate assembly stuff you know
<heat>
why are you comparing C to assembler?
<Andrew>
Because types don't exist
<heat>
C is not a low level language
<Andrew>
heat: How is this a comparison?
<\Test_User>
we're talking about 2 at once
<Andrew>
Well, they're similar in the case of memory management, both are unsafe
<\Test_User>
not comparing directly, though there is comparison to the overflow/carry flag for what is possible
<Andrew>
But, true C has types
<heat>
assembly is barely a language
<heat>
what's memory management in assembly? sub $8, %rsp?
* geist
yawns
<geist>
how is everyone
<Andrew>
"mov"
<heat>
geist, fine. how are you?
<\Test_User>
memory management in assembly is what you write it to be
<Andrew>
register management[tm]
<\Test_User>
I'm doing fine
* Andrew
fills \Test_User with null bytes
* \Test_User
passes Andrew a nullptr
* psykose
fills |Test_User with 0x4 bytes
<heat>
nullptr?????
<heat>
this is C homie
<heat>
pass him NULL, or 0, nothing matters really
* geist
tries to catch up with this conversation but guesses it's not worth it
<psykose>
it isn't
* geist
thumbs up
<Andrew>
it's just chitchst
<\Test_User>
yes but nullptr is more obvious when spoken
<Andrew>
*chitchat
<geist>
roger roger
<\Test_User>
or rather, when typed in IRC :P
<heat>
I said C is crap and they're saying it isn't
* Andrew
passes \Test_User a derlict corvi
<heat>
which it is, every language is crap
<heat>
i'm yet to find a good one
<Andrew>
heat: HeatLabg
<heat>
it's exactly like build systems
<Andrew>
*HeatLang
<heat>
naw i'm good
<\Test_User>
every language is crap - sure I'll agree to that, but *in comparison*, I find C to be one of the less crap ones
<Andrew>
heat: I think MMIX Assembly is a good language is you ignore its CamelCase
<Andrew>
Let's just use JavaScript for OS Dev
<\Test_User>
Andrew: that's still assembly
<\Test_User>
lol jsos
<Andrew>
s/J.*t/HTML and CSS/
<\Test_User>
jSOS
<heat>
that's possible
<heat>
OS on top of electron
<Andrew>
\Test_User: Yes it is still assembly but mmix assembly is much better than x85 assembly
<heat>
who says no?
<Andrew>
AHHHAHHAHA
<Andrew>
NOONIININNIAJSSS
<Andrew>
HSHDH
<heat>
you good?
<kingoffrance>
he is being punished for the js statement
<kingoffrance>
purified
<Andrew>
xD
<\Test_User>
XD
<kingoffrance>
let us pray
<Andrew>
That was a joke :D
<kingoffrance>
speak of the js
<Andrew>
And someone extended it to electron
<Andrew>
No I will not learn Ajs
<Andrew>
*JS
<Andrew>
In fact my primary browser doesn't support JS
<Andrew>
\Test_User: Big endian, thanks
* \Test_User
passes Andrew his little-endian assembler and hd
<\Test_User>
(still not yet created sadly)
<Andrew>
if the rest of the language is written in hebrew or arabic or similar
<\Test_User>
lol
<Andrew>
I accept little-endian
<Andrew>
If it's in english
<Andrew>
I want big-endian
<\Test_User>
little-endian in english ofc, I don't know little-endian languages nor can my keyboard easily type that rn
<Andrew>
what the heck is middle-endian
<\Test_User>
insanity
<\Test_User>
probably something that never should have existed
<\Test_User>
idc, the point of such an assembler and hexdump is to get them used to looking at it for how it is when stored in ram
<\Test_User>
(idc about confusing people initially looking at it)
nullptr is now known as nil
<Matt|home>
opinion : in general is there an advantage to running say openbsd to host my servers versus like fbsd or something, or are the security advantages negligible over convenience? or should it be paranoia at all times 100% since this is publicly accessible
<Matt|home>
er
<Matt|home>
wrong channel
<Matt|home>
sry
<Andrew>
Matt|home: Even though this is the wrong channel; I prefer OpenBSD not really because of its security but because there aren't nonfree drivers or nonfree blobs in the kernel to worry about; OpenBSD's code quality is really good which is also a factor for me to like OpenBSD better, though security-wise OpenBSD and FreeBSD_with_TrustBSD aren't really different
<Matt|home>
i remember open being a pain in the ass to work with the last time.. but that was well over a decade ago
<Matt|home>
and i know a lot of servers run fbsd now
<geist>
yah my main concerns nowadays would be running openbsd on high end machines. i get the feeling it doesn't scale as well, etc
<geist>
but for simple single tasked servers i bet it's fine
<Andrew>
Open is easy to work with IMO; I'm using debian on my most-public server now for one reason: GNUnet, which hasn't been ported over yet
<Matt|home>
my main concern is that im gonna be running these on my main desktop.. like.. i use banking and shit on here
<Andrew>
geist: No SMP in the kernel isn't a big performance hit even fore quite performant machines in my experience
<Andrew>
I use OpenBSD as my primary desktop
<heat>
openbsd has a BKL?
<Andrew>
Along with some other systems
<Matt|home>
i suppose i can learn a bit about both. it's been a long time since i did any bsd sys admin stuff. i used to know a lot about it :D
<Andrew>
Forgot what bkl meant
<j`ey>
big kernel lock
<heat>
big kernel lock
<Matt|home>
the hell is that
<geist>
yah ii just dont think open and netbsd have been able to keep up with that, netbsd in particular
<geist>
but i am possibly just entirely wrong
<Andrew>
Not sure if there's a bkl
<geist>
ie, for simple 4-8 cpu machines they're probably fine for light load
<Andrew>
But openbsd kernel has not as good multicre
<mrvn>
Matt|home: There are basically 2 security scenarios you have to cover: Mossad and not Mossad.
<heat>
As of July 2019, OpenBSD and NetBSD are still using the spl (Unix) family of primitives to facilitate synchronisation of critical sections within the kernel,[4][5][6] meaning that many system calls may inhibit SMP capabilities of the system, and, according to Matthew Dillon, the SMP capabilities of these two systems cannot be considered modern.[7]
<Andrew>
but performance wise it's totally fine, *for me*
<Matt|home>
ah. that's a neat idea
<Matt|home>
only 1 thread in kernel space at a time
<Matt|home>
i like that
<heat>
neat?
<geist>
oh sure
<Andrew>
but for your usecases, trustbsd on freebsd is enough
<geist>
it's the standard first step of taking a non SMP kernel into the SMP world: keep one thread in the kernel at a time
<Andrew>
in fact, selinux on a linux-based system would be enough
<geist>
then you start breaking that up. lots of older kernels went through that path
<Matt|home>
... i dont supose anyone knows where i put my phone
<mrvn>
Matt|home: why don't you call yourself. :)
<Andrew>
I know where my phone is because it's in a lead cage all the time except when the government wants a dynamic qr code health code from it
<heat>
Andrew, linux is relatively secure
* Andrew
looks at Linux CVEs
<heat>
plenty of eyes, plenty of very compentent, experienced devs and maintainers
<Andrew>
Though, Linux with SELinux is pretty secure
<heat>
openbsd has a much lower usage
<mrvn>
Andrew: If the Mossad wants your password they just get your to tell them. And if it's not the mossad attacking you they aren't going to hack your server.
<heat>
a lot fewer eyes
<Andrew>
Indeed
<Andrew>
mrvn: Mossad?
<mrvn>
Andrew: Mossad is the
<mrvn>
national intelligence agency of Israel, really badass
<Andrew>
Ah
<mrvn>
i.e. professionals
<Andrew>
Well
<Andrew>
(1) My classmates attack my server all the time
<Andrew>
though their attacks are really rudimentry
<mrvn>
It's more likely you get triuckerd into some scam via email or web pages than someone hacking your desktop.
<Andrew>
Any sane setup, even eithout zMac will do
<\Test_User>
"or accidentally pasting your passwords..."
<Andrew>
(2) I don't use modern Web browsers and stuff, a little harder to scam me
<Andrew>
\Test_User: Alright fair enough - but I had a sane allowmask
<Andrew>
And I don't do online payment
<\Test_User>
mostly fair enough
<\Test_User>
~~add some filter to block you from pasting passwords where they shouldn't go~~
<Andrew>
(Sometimes when I'm tired (like now) I might do something like paste passwords into the inspircd help channel when configuring inspircd)
<mrvn>
The best way to not get hacked by your friends: To given them any service to hack.
<heat>
take away their ability to pwn you with scripts and you're safe
dude12312414 has joined #osdev
<Andrew>
heat: if the crackers are os developers that's another story
<Andrew>
(assembly is quite critical to real cracking)
<GeDaMo>
osdevs break their own systems :P
<Andrew>
trur lol
<Andrew>
\Test_User: suffering from spectre and meltdown?
<\Test_User>
no
<\Test_User>
just wanting to ensure it can't happen
<heat>
im too busy trying to figure out why processes sometimes crash under heavy load to write csgo best hack aim wall bhop 2022 updated see link in the description
<\Test_User>
well, at least, not that I know of :P
<\Test_User>
will get around to reading all of the other major ones as well eventually
<Andrew>
\Test_User: Plate your CPU with regenerating plastanium to fix it
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
wereii_ has quit [Ping timeout: 255 seconds]
wereii has joined #osdev
foudfou has joined #osdev
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat_ has quit [Remote host closed the connection]
heat has joined #osdev
diamondbond has quit [Ping timeout: 246 seconds]
heat has quit [Remote host closed the connection]
heat has joined #osdev
knusbaum has quit [Ping timeout: 255 seconds]
knusbaum has joined #osdev
mahmutov has quit [Ping timeout: 258 seconds]
rpnx-phone has quit [Ping timeout: 240 seconds]
rpnx-phone has joined #osdev
<zid>
heat: Did you finish my wallhack yet
<zid>
I want to finally get to silver 2
heat has quit [Remote host closed the connection]
heat has joined #osdev
<zid>
He's done a runner!
<zid>
oh he's back already nevermind
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
Likorn_ has quit [Quit: WeeChat 3.4.1]
<heat>
zid, no im busy
<heat>
maybe next month
<heat>
hopefully I wont postpone it enough that I need to change the name to "csgo best hack aim wall bhop 2023 updated see link in the description"
Terlisimo has quit [Quit: Connection reset by beer]
vdamewood has quit [Remote host closed the connection]