<zid>
yea I think on windows and linux it's opposite also
<zid>
64bit forces gs to be the task struct, more or less
<mjg>
not the teask struct, the per-cpu thing which also has a pointer to the task
SGautam has quit [Quit: Connection closed for inactivity]
GeDaMo has joined #osdev
<damo22>
why dont we use the segment registers in userspace to have files == different memory segments
<damo22>
like a super ramdisk that partitions ram
<GeDaMo>
Other than fs and gs, segment registers don't work in x86 64-bit mode
<GeDaMo>
"Four of the segment registers, CS, SS, DS, and ES, are forced to base address 0, and the limit to 264. The segment registers FS and GS can still have a nonzero base address." https://en.wikipedia.org/wiki/X86_memory_segmentation
<damo22>
ok
<GeDaMo>
s/264/2^64/
<zid>
264 is funnier
qookie has quit [Read error: Connection reset by peer]
Arsen has quit [Read error: Connection reset by peer]
qookie has joined #osdev
Arsen has joined #osdev
frkazoid333 has quit [Remote host closed the connection]
ThinkT510 has quit [Quit: WeeChat 4.0.3]
ThinkT510 has joined #osdev
<asarandi>
not exactly osdev, i'm working on a ctf challenge. the program generates a random address where it mmap's the flag file. the challenge is to figure out the memory address. all syscalls are disabled via seccomp. challenge comes bundled with a specific libc.so version 2.31, author says that there is a way to test memory pages and check if mapped/unmapped using some libc mechanism without causing
<asarandi>
access violation, any ideas about this? thank you
<bslsk05>
www.man7.org: signal(2) - Linux manual page
<asarandi>
GeDaMo: that's with syscall
<GeDaMo>
"By default, in glibc 2 and later, the signal() wrapper function does not invoke the kernel system call. Instead, it calls sigaction(2) using flags that supply BSD semantics."
<klange>
That's still a system call, just a different one.
<zid>
sys_rt_sigaction?
<zid>
I don't actually know how linux does signals
<zid>
do you get a generic 'signal' then you switch on the code, or do you register for each possible signal? etc
<klange>
Linux has a lot of 'legacy' system calls that are not used but continue to exist to 'not break userspace' in the case of statically-compiled binaries
<damo22>
xchgw %fs, %gs <--- is that valid?
<zid>
don't believe so, 2 seconds will an assembler will tell you thoug
<zid>
I think basically the only encodings available are mov seg, ax
<asarandi>
i had some success with `prefetcht2` instruction and timing its duration via `rdtsc` - it is possible to discern between mapped and unmapped pages, however this is not the correct approach in this case because of the way `mmap` works where it does it's "lazy" thing and files are not truly mapped until first access
<zid>
that actually makes timing attacks much much easier
<zid>
but yea, not much help to you
<asarandi>
yes but like i said .. the flag is never truly mapped, so the timing approach fails
<zid>
clearly the solution is *(int *)rand()
<zid>
be luckier
<asarandi>
oh the proggie reads a seed from /dev/urandom so no luck there lol
<klange>
The 'right' way to determine what memory is mapped for your process on Linux is to read /proc/$PID/maps, if you can.
<zid>
that'd need many syscalls
<klange>
On x86-64, probing of any sort would be mathematically infeasible.
<zid>
meh it's only 34 billion pages to check
xenos1984 has quit [Read error: Connection reset by peer]
<asarandi>
it's random in range, i think i'd have to probe a max of 27k pages
<mjg>
asarandi: you could do prefetch twice?
<mjg>
but then again, i'm surprised to find it does not crash
<bslsk05>
www.ebay.co.uk: NEW UNUSED INTEL C4002-2 DATE 1976 - PHILIPPINE - IN PLASTIC HOLDER - C4004 | eBay
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 258 seconds]
* gog
drops the vase from the shelf to the floor
<sham1>
Quit breaking vases!
<Ermine>
Nooo vases!
<zid>
like any of us own vases
phoooo has joined #osdev
<mjg>
i no longer do
<mjg>
thanks gog
<phoooo>
rather a question that requires an opinionated answer, but just asking to know what do you think. i am working on a tiny riscv os, would you go with virtio for the filesystem or just a plain initrd
<zid>
depends on how late stage capitalism I am
<zid>
initrd for small kernel, initrd for massive kernel
<zid>
virtio for medium
<sham1>
Well virtio isn't a filesystem, is it?
<sham1>
IIRC the actual filesystem in use there is 9p2000
<zid>
I don't think it was that usage of 'for'
<zid>
virtio for (the filesystem) not virtio (for the filesystem)
<zid>
sham1: that's virtio-9p anyway, there's also you know, virtio-blk
<zid>
like people actually use
<sham1>
Well in that case the question makes no sense since whether or not you're using virtio-{9p,blk} has no bearing on the use of an initrd
<phoooo>
i was asking whether to use virtio-blk+{fat32, ext2} or just a tar initrd
<phoooo>
might have phrased it wrongly
<zid>
nah he's just being awks
<zid>
I got what you meant
<zid>
and I stick by my answer
<sham1>
I still don't quite understand why it's a either-or question in that case
<sham1>
You can have both
<sham1>
Maybe tar would be easier at the outset, but you want to have block device support eventually
<zid>
small kernel: just go with an initrd, there is no fs support, very large kernel: fat32/ext2 is now a driver so you need an initrd again, medium: You just hardcode everything to the one fs you support
<zid>
:P
<sham1>
And in that case you could make the virtio-blk driver into a module to be loaded, yeah
<sham1>
Alongside the FAT or ext2 driver
<phoooo>
yeah, of course, just wanted to have a barebones file system for the moment
<phoooo>
so as to load some binaries and such
<sham1>
Well I'd go with tar or some such
<phoooo>
yeah
<sham1>
USTAR is after all a quite simple format. Although I do wonder whether anyone supports the pax format by POSIX which is essentially just USTAR but extended
<zid>
isn't an initrd in cpio format
<zid>
normally
<phoooo>
on linux it is
<phoooo>
i dont know about other systems tho
<phoooo>
i mean, both tar and cpio are kinda similar
<sham1>
There's also squashfs which is also similar
<zid>
ooh yea squashfs
<phoooo>
isn't squashfs compressed
<zid>
I'd hope so
<zid>
otherwise they named it really terribly
<sham1>
Yeah
rb has quit [Ping timeout: 245 seconds]
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
rwb has joined #osdev
terminalpusher has joined #osdev
frkazoid333 has joined #osdev
phoooo has quit [Quit: Client closed]
troseman has joined #osdev
troseman has quit [Client Quit]
[itchyjunk] has joined #osdev
troseman has joined #osdev
heat has joined #osdev
<heat>
hi
<heat>
i had a dream where geist asked me for details on the PCI option ROM format and how EFI drivers can fit there
<heat>
really woke up after that, no one is nerd sniping me in my dreams
<heat>
btw initrds need a tmpfs
<heat>
tar and cpio are *not* filesystems
<heat>
they have no hierarchy whatsoever, it's just a collection of pathnames + stat info + data
<sham1>
Down with the hierarchies, up with the databases!
goliath has joined #osdev
zxrom has joined #osdev
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #osdev
Burgundy has quit [Ping timeout: 250 seconds]
<zid>
heat: I just uncompress and while I do it, build a prefix tree of the files
<sham1>
Yeah, it is a file system. It's just not serialised tree-wise
<zid>
ssd too fast, need a filesystem optimized for it, that doesn't use a tree structure
<zid>
and ram is even faster
heat has quit [Ping timeout: 246 seconds]
kingoffrance has quit [Ping timeout: 252 seconds]
<gog>
hi
<gog>
you know where you won't find any trees
<GeDaMo>
The moon?
<zid>
carpark
<zid>
icelandfs
<zid>
It's like a normal fs but it's got moss on it instead?
<zid>
I think a moss is where you just put everything thinly spread over everything, basically an array?
<Ermine>
gog: may I pet you
<Ermine>
google spreadsheet dates are insane
<zid>
At least in spreadsheets the glass is 2nd of february full
<zid>
2nd of january*
<mjg>
personally i'm the "glass is crap" kind of guy
FreeFull has joined #osdev
ourdumbfuture has joined #osdev
<gog>
Ermine: yes
* Ermine
pets gog
* gog
prr
<gog>
i liek glass it's my favorite material
<gog>
it's elegant and smooth and if you break it you can use it as a weapon
<gog>
like me
kof123 has joined #osdev
<GeDaMo>
Borosilicate is best glass
<gog>
yes
<gog>
it does not afraid of rapid temperature changes