<heat>
ok so basically ELF files are mmap'd (by both the kernel, when loading the initial executable; and the ld.so loading shared libraries)
<monkeyPlus>
But i ran the same program, and sqrt() always loaded at same address
<zid`>
now LD_PRELOAD some other crap in :P
<heat>
so the choice of placement depends on the algo the kernel uses, and the order in which you load things
<zid`>
or update some packages
<monkeyPlus>
ive tried several libraries, and they all used the same memory address
<heat>
and that algo is pretty deterministic, so it really depends on the order and sizes of stuff
<monkeyPlus>
so, why can't i know the address of a shared library? that's not true, its fixed
<heat>
yes, for the same program, it will work out
<heat>
it does not work out for different programs
<heat>
for the libc and ld.so that might just happen to work out, due to them being loaded first and (on linux) far away from the main program, even when PIE is involved
<ring0_starr>
was it compiled as dynamic?
<ring0_starr>
do you have aslr disabled by sysctl?
<monkeyPlus>
ok...so no, even if its a different program, always the same memory addresses
sortiecat has joined #osdev
<monkeyPlus>
this is weird..what if i have many functions
<heat>
that's unlikely
<heat>
take pmap and run it on a bunch of processes
<heat>
you'll see the differing load order
<monkeyPlus>
so...its possible, they are on same address space, but unlikely?
<heat>
yes, it is possible
<heat>
it is, like, 100% guaranteed if it is the same program with the same libs linked in the same order
<monkeyPlus>
what does you mean, same program?
<ring0_starr>
what is the point of pmap
<heat>
because program loading is deterministic and dynamic library loading is deterministic and mmap is deterministic
<heat>
same binaries
<heat>
ring0_starr, printing vm areas
<ring0_starr>
i literally never heard of it and was using /proc/pid/maps until now
<heat>
i mean, it does a bit of parsing
<heat>
it's neat
<monkeyPlus>
what if the binaries arent equal
<heat>
then everything can change
<monkeyPlus>
ok so compilation, affects the way, shared libraries are loaded into memory address spcae
<heat>
if a library is loaded in a different order, that screws it up. if the size is different it shifts everything up/down
<monkeyPlus>
ok. So functions, on the program (not shared libraries), are loaded at a fixed address?
<monkeyPlus>
im compiling different binaries, and shared libraries are loaded on same address spcae
<heat>
i mean i literally told you what changes it
<heat>
run pmap or cat /proc/<pid>/maps
<heat>
you'll see different addresses, because of possible different link ordering
<heat>
like, if all you have is various programs linked to libc.so, everything will have the same address, despite changing sizes or whatnot
<ring0_starr>
objdump -f <binary in question> | grep DYNAMIC
<heat>
due to the main program either having a fixed address (if not PIE) far away, or having a non-fixed address still far away (PIE on linux x86_64 loads the program at 0x55...., whereas shared libraries are around 0x7f...., so a bunch of terabytes away)
<monkeyPlus>
so. Its possible that address space are the same, and different files
<heat>
yes
<monkeyPlus>
ok
<monkeyPlus>
thks
<heat>
you're welcome
<monkeyPlus>
:)
<heat>
a trivial way to check this is to LD_PRELOAD something, as zid said
<monkeyPlus>
what do you mean binary files different ? like different asm instructions!?
<heat>
no
<heat>
binary files different as in virtual memory layout different, or as in shared library dependencies different (ordering DOES matter)
<monkeyPlus>
ah ok
<monkeyPlus>
when you say ordering matters, mean lib1() ; lib2(); not equal to lib2() ; lib1() ?
<monkeyPlus>
this ordering is because shared libraries dependency between them?
<heat>
idk why you're including ();
<monkeyPlus>
ah lol
<monkeyPlus>
call to a library :)
<heat>
i'm not talking about calls, im talking about deps
<monkeyPlus>
ah
<heat>
i mean "depends on: libc.so, libssl.so" is different from "depends on: libssl.so, libc.so" because the dynamic linker will load those same libs in a different order
<klys>
gcc -l1 -l2; not equivalent to gcc -l2 -l1; iow
<monkeyPlus>
ok. So if i have a binary, and run it, it always load at a fixed address...why is understood, that we don't know the shared library address?
<monkeyPlus>
for the same binary...
<heat>
what?
<heat>
i dont get your question
<monkeyPlus>
ok. For same binary, it will load every shared library (no matter what library), is going to be loaded at the same fixed address
<klys>
shared library lib1.so is probably a symlink, to something like lib1-1.0.1.so
<monkeyPlus>
that means...like the process, reservers ALL memory to hold the shared libraries, because it doesnt know how many
<heat>
no
<heat>
that is quite literally not how it works
<klys>
if you upgrade lib1.so to lib1-1.2.3.so, it still runs
<heat>
i did tell you it uses mmap, and the order matters
<heat>
read up on it if you want
<monkeyPlus>
because strcpy -> address X , printf -> address Y ...since they are on fixed addresses, what happens if i have another library, that uses the same address?
<heat>
and mmap on no-aslr is deterministic, which is why running the same program multiple times on no-aslr will always give you the same memory layout
<heat>
they are not on fixed addresses, i have told you that many times
<heat>
libraries are relocated. whether it's the same address or not does not matter, this is not PE, every shared object is fully relocatable
<heat>
position-independent-code
<monkeyPlus>
but you said, for the same binary, same address space used by libraries right
<geist>
think of it as multiple binaries are running at the same time, with a different batch of shared libs at the same time
<geist>
so there's not one good spot for any given shared lib to load at, since each process will have a different layout
<geist>
(asterisk, there is ways to do this, but it's mostly out of vogue now with ASLR)
<klys>
so right, you're running your program, and it's ELF. so it is loaded by the linker-loader at /lib64/ld-linux.so.2 for example (didn't look too close); that goes through all your pointers to lib1.so and adjusts "reloacates" them to point to where mmap put them.
<geist>
right, think of each process as it's own little universe, doesn't care what everything else is doing. the loader just constructs each of them in isolation, puts the shared libs where it sees fit that instant
<geist>
if that happens to be at the same spot as other processes that's just a coincidence
<monkeyPlus>
im talkking about same binary
<monkeyPlus>
not different binaries
<geist>
ure, but you need to define what 'same binary' means in this case?
<klys>
okay your binary uses the linker-loader, so it isn't self-contained.
<heat>
i'll be brutally honest here, i think you're in way over your head
<geist>
like, a single instance of a single file on disk?
<heat>
because i've explained the same concepts like 4 or 5 times and now you have 3 people explaining this to you and you still dont get it
<monkeyPlus>
ok let me reread
<monkeyPlus>
i didnt fully understand the concept of deterministicxs
<geist>
i think you're making it more complicated than you need monkeyPlus
<monkeyPlus>
and different binaries
<geist>
think of each individual process as being it's own thing
<monkeyPlus>
ok..for the same process, always the same fixed addresses
<geist>
every time one is created it's from the ground up, and it makes a bvunch of choices right then
<geist>
well... i mean for an individual process it only really loads thingfs once
<geist>
so thats not really a meaningful statement
<monkeyPlus>
im saying this, because i wroten several c programs, that when ran and compiled (meaning conceptually,could be different binaries), and they have the same fixed address
<geist>
when i say 'process' i mean an instance of a single program. if you run the same program 5 times that's 5 separate processes
<geist>
5 seperate 'instances' of that process
<geist>
5 seperate 'instances' of that program
<heat>
deterministic: 'For a given particular input, always producing the same output through the same sequence of states.'
<heat>
ASLR-less program loading is (generally) deterministic because given the same inputs it will always produce the same output
<heat>
through the same sequence of states
<geist>
this is where you also get highly into each individual OSes are doing, or different distros of any given OS
<geist>
sometimes the program is laoded at the same spot, sometimes they're not
<geist>
and yeah, *in general* in an ASLRless environment the program binary is loaded at a fixed spot, but the shared libraries it brings in are not
<klys>
and yes, you can have the same address space for different processes simultaneously. they won't see each other, that's because the address space only includes the current process and whatever libraries were loaded by the linker-loader (and the vdso stub, typically at a random place).
<geist>
exactly
<heat>
the vdso stub isn't randomly placed
<heat>
it is exactly as random as the rest of the mmap()
<heat>
which is to say, random-ish on ASLR, not random if its off
<monkeyPlus>
klys, same virtual address space right
<klys>
monkeyplus, yes those are virtual addresses. physical addresses for your stuff generally cannot be determined.
<heat>
i want to mention we are talking about virtual address *layouts*
<heat>
multiple processes do not share the same virtual address space
<geist>
right, even the same program running multiple times at the same time, those are different processes
<zid`>
it's added as an *import* by default, by the C compiler
<zid`>
but it isn't loaded by default by the OS
<monkeyPlus>
so why can't i see the c functions on "nm"
<zid`>
make sure you have the right flags
<monkeyPlus>
ah ok
<heat>
nm will not show you symbols from libc.so
<heat>
zid`, that's not true
xenos1984 has quit [Read error: Connection reset by peer]
<heat>
ELF dependencies are always loaded
<monkeyPlus>
ok..
<zid`>
nm -D /bin/ls -> strcpy/strrchr/strcmp/...
<monkeyPlus>
cool
<heat>
yes, those are imports
<heat>
everything marked 'U' or UND are undefined symbols that will (hopefully) be resolved by ld.so
<zid`>
# ldd /bin/ls
<zid`>
libc.so.6 => /lib64/libc.so.6
<heat>
ELF doesn't even keep track of where symbols are supposed to come from
<heat>
which is why LD_PRELOAD just works
<monkeyPlus>
but, like libc, is linked but nm only shows which are used?
<heat>
yes
<monkeyPlus>
ok
<monkeyPlus>
:)
<zid`>
there's a list of symbols it wants in order to work
<zid`>
and a list of .so files it wants
<heat>
why do you care about all of this?
<heat>
are you doing a ret2libc
<monkeyPlus>
yes
<heat>
please dont ask us hacking tips, thanks
<heat>
i regret answering
<monkeyPlus>
okay
<heat>
i'll sleep at night knowing you can only hack systems from 2006, but still
<monkeyPlus>
ok, so libc is not fully linked to the program?
<monkeyPlus>
only those functions?
<zid`>
You might wanna learn how to program *first*
<zid`>
rather than last
Left_Turn has joined #osdev
<heat>
yo zid` have i posted that vid of a new windows xp install getting hacked in like 2 or 3 different ways in some 15 minutes, just by being connected to the internet
<zid`>
w7 has the same issue, the installer is ancient and you're supposed to windows update it to shit
<zid`>
takes hours lol
<heat>
how do you windows update it to shit before getting hacked?
<zid`>
NAT
<monkeyPlus>
so, why do they say that libc, is linked by default
<heat>
hmm yes NAT does work
<zid`>
also, when you add vista+ to a network it asks you how 'safe' the network is
<heat>
<heat> please dont ask us hacking tips, thanks
<zid`>
you can click 'this is a café don't open ANY smbios ports'
<zid`>
which safes you from a lot of it
<heat>
yeah but how effective the win firewall is depends on the network stack not being fucked
<heat>
and there was even a high profile RCE on ipv6 a year or so ago? so yeah
<zid`>
Thankfully all of the CVEs that exist in the base install don't transmit over ipv4 lans
<zid`>
so if you just stck it being ipv4 only NAT, on a 'trusted' lan, you're fine still
<zid`>
being/behind
<heat>
ah the vid is using SP3
<zid`>
There's no sp3 installer though
<zid`>
you can 'make' them sorta though
<heat>
yeah i guess he installed it before
<zid`>
include the sp3 cabs in the installer disk, rufus or whatever could do it
<zid`>
'slipstreaming' they called it
xenos1984 has joined #osdev
Left_Turn has quit [Read error: Connection reset by peer]
heat has quit [Ping timeout: 252 seconds]
<cloudowind>
sortiecat geist mention about the lack of advertisers and artists for open source community , yes lot of volunteer coders but imo what is missing is opensource needs volunteer advirtisers and artists etc, inorder to make some advertisement and bring some income to those who codes for open source
<cloudowind>
because there are so many rock solid alternatives for macos and microsoft products on linux which does the things with the same quality with those paid ones , but people who create those beautiful things are not being awarded enough for their contributions imo
<cloudowind>
anyway , goodays people
* kof673
be careful what you wish for .oO( future kof website, user clicks "K & R code" -> goatse logo appears )
<kof673>
as the code becomes more modern, the logos become more tasteful, but that is the lowest of the low
<the_oz_>
search engines making pdf links worthless
<the_oz_>
lower than the scammers that fake content
<the_oz_>
engines are supposed to work, not return bullshit
<the_oz_>
knowingly!
sortiecat has quit [Read error: Connection reset by peer]
surabax has quit [Quit: Leaving]
sortiecat has joined #osdev
<cloudowind>
as in those artists and advitisers maybe even philosophers , spread out there the importance of free open tehcnology for humanity ...
<cloudowind>
which in return can turn into donations , some extra income for those beautiful hearted people
Halofreak1990 has quit [Ping timeout: 252 seconds]
m5zs7k has quit [Ping timeout: 245 seconds]
m5zs7k has joined #osdev
m5zs7k has quit [Ping timeout: 248 seconds]
sortiecat has quit [Read error: Connection reset by peer]
sortiecat has joined #osdev
sortiecat has quit [Read error: Connection reset by peer]
sortiecat has joined #osdev
sortiecat has quit [Read error: Connection reset by peer]
m5zs7k has joined #osdev
sortiecat has joined #osdev
monkeyPlus has quit [Remote host closed the connection]
dysthesis has joined #osdev
m5zs7k has quit [Ping timeout: 252 seconds]
m5zs7k has joined #osdev
Halofreak1990 has joined #osdev
Halofreak1990 has quit [Ping timeout: 244 seconds]
joe9 has quit [Quit: leaving]
Halofreak1990 has joined #osdev
AFamousHistorian has joined #osdev
AFamousHistorian has quit [Remote host closed the connection]
AFamousHistorian has joined #osdev
Halofreak1990 has quit [Ping timeout: 244 seconds]
sortiecat has quit [Read error: Connection reset by peer]
sortiecat has joined #osdev
goliath has joined #osdev
sortiecat has quit [Ping timeout: 260 seconds]
sortiecat has joined #osdev
vin has quit [Quit: WeeChat 2.8]
sortiecat has quit [Read error: Connection reset by peer]
sortiecat has joined #osdev
sortiecat has quit [Read error: Connection reset by peer]
sortiecat has joined #osdev
sortiecat has quit [Client Quit]
craigo has joined #osdev
Lucretia has joined #osdev
dysthesis has quit [Remote host closed the connection]
Halofreak1990 has joined #osdev
craigo has quit [Ping timeout: 252 seconds]
bauen1 has quit [Ping timeout: 276 seconds]
mobivme has joined #osdev
thisisjaymehta has quit [Ping timeout: 246 seconds]
heat has joined #osdev
<heat>
kern
<alifib>
it's in the name of that book, kerningham and ritchie
<alifib>
doh
mobivme has quit [Ping timeout: 248 seconds]
osmten has joined #osdev
<Ermine>
vmkern
<geist>
ovmkern
<heat>
i'm so early geist is still here
<heat>
crazy stuff
<geist>
thats pretty early
<zid`>
ritchieal when
<pog>
koral
<pog>
geist go to bed
SGautam has joined #osdev
GeDaMo has joined #osdev
<nikolar>
krnl
<pog>
yes
Halofreak1990 has quit [Ping timeout: 260 seconds]
\Test_User has quit [Ping timeout: 265 seconds]
Halofreak1990 has joined #osdev
bauen1 has joined #osdev
hwpplayer1 has joined #osdev
Halofreak1990 has quit [Ping timeout: 265 seconds]
melnary_ has joined #osdev
melnary has quit [Read error: Connection reset by peer]
agent314 has quit [Quit: No Ping reply in 180 seconds.]
melnary_ is now known as melnary
agent314 has joined #osdev
Left_Turn has joined #osdev
cloudowind has quit [Ping timeout: 248 seconds]
cloudowind has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 246 seconds]
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 246 seconds]
ryoskzyp1 has quit [Ping timeout: 264 seconds]
ryoskzypu has joined #osdev
heat_ has joined #osdev
heat has quit [Ping timeout: 248 seconds]
Turn_Left has joined #osdev
cloudowind has quit [Remote host closed the connection]
Left_Turn has quit [Ping timeout: 244 seconds]
cloudowind has joined #osdev
osmten has quit [Quit: Client closed]
alifib has quit [Quit: .]
Ermine has left #osdev [WeeChat 4.3.1]
Ermine has joined #osdev
SGautam has quit [Quit: Connection closed for inactivity]
levitating has joined #osdev
Halofreak1990 has joined #osdev
Halofreak1990 has quit [Ping timeout: 276 seconds]
surabax has joined #osdev
antranigv has quit [Read error: Connection reset by peer]
antranigv has joined #osdev
sortiecat has joined #osdev
Halofreak1990 has joined #osdev
eddof13 has joined #osdev
GreaseMonkey has quit [Ping timeout: 276 seconds]
edr has joined #osdev
Left_Turn has joined #osdev
goliath has quit [Quit: SIGSEGV]
Turn_Left has quit [Ping timeout: 244 seconds]
Turn_Left has joined #osdev
AFamousHistorian has quit [Quit: Leaving]
Left_Turn has quit [Ping timeout: 244 seconds]
sortiecat has quit [Read error: Connection reset by peer]
sortiecat has joined #osdev
sortiecat has quit [Read error: Connection reset by peer]
sortiecat has joined #osdev
xenos1984 has quit [Ping timeout: 252 seconds]
sortiecat has quit [Read error: Connection reset by peer]
sortiecat has joined #osdev
sortiecat has quit [Read error: Connection reset by peer]
xenos1984 has joined #osdev
sortiecat has joined #osdev
heat has joined #osdev
heat_ has quit [Ping timeout: 246 seconds]
eddof13 has quit [Quit: eddof13]
sortiecat has quit [Read error: Connection reset by peer]
sortiecat has joined #osdev
m3a has joined #osdev
xenos1984 has quit [Ping timeout: 248 seconds]
agent314 has quit [Ping timeout: 244 seconds]
eddof13 has joined #osdev
xenos1984 has joined #osdev
Halofreak1990 has quit [Ping timeout: 260 seconds]
stolen has joined #osdev
goliath has joined #osdev
xenos1984 has quit [Ping timeout: 246 seconds]
xenos1984 has joined #osdev
gog has joined #osdev
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 260 seconds]
Left_Turn has quit [Remote host closed the connection]
Left_Turn has joined #osdev
sortiecat has quit [Read error: Connection reset by peer]
sortiecat has joined #osdev
xenos1984 has quit [Ping timeout: 246 seconds]
getz has quit [Quit: A mystery...]
sortiecat has quit [Read error: Connection reset by peer]
kilic_ has quit [Ping timeout: 248 seconds]
kilic has joined #osdev
getz has joined #osdev
xenos1984 has joined #osdev
sortiecat has joined #osdev
sortiecat has quit [Read error: Connection reset by peer]
sortiecat has joined #osdev
n_shp is now known as nshp
sortiecat has quit [Read error: Connection reset by peer]
sortiecat has joined #osdev
flx has quit [Quit: WeeChat 4.4.3]
<heat>
fs/coda/upcall.c
fsinger has joined #osdev
fsinger is now known as flx
sortiecat has quit [Read error: Connection reset by peer]
sortiecat has joined #osdev
Halofreak1990 has joined #osdev
<nikolar>
KORINAL
HeTo_ has quit [Quit: kernel update]
Halofreak1990 has quit [Ping timeout: 248 seconds]
goliath has quit [Quit: SIGSEGV]
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
bradd has quit [Remote host closed the connection]
\Test_User has joined #osdev
Halofreak1990 has joined #osdev
bradd has joined #osdev
GreaseMonkey has joined #osdev
<Ermine>
nikolar: you gotta write an os with this name