[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology


Thread archived.
You cannot reply anymore.


[Advertise on 4chan]


File: 1737350176503157.png (112 KB, 505x515)
112 KB
112 KB PNG
previous: >>107909236

#define __NR_pread64            17

https://man7.org/linux/man-pages/man2/pread.2.html

this one is pretty interesting! it's actually a syscall i hadn't heard of before. basically, it's read, but from an offset. now, you might be wondering - like i was - what possible use case there is for something like this, but actually, it totally makes sense.
>The pread() and pwrite() system calls are especially useful in multithreaded applications. They allow multiple threads to perform I/O on the same file descriptor without being affected by changes to the file offset by other threads.
pretty handy!

relevant resources:
man man

man syscalls

https://man7.org/linux/man-pages/
https://linux.die.net/man/
https://elixir.bootlin.com/linux/
https://elixir.bootlin.com/musl/
https://elixir.bootlin.com/glibc/
>>
I need to make an archive of those posts somehow. Hopefully desuarchive has some sort of API to get all those syscall of the day posts. They are kind of entertaining and it's always joyful standing up in the morning and see a new of those threads.

In regards to pread64, it does seem interesting, I never do anything with multiple threads, but it seems like it could have more usecases beside that, maybe with networking or something.
>>
I don't know anything about programming, is this an assembly language thread? I saw an assembly tutorial and it had syscall and that "_word" notation in it
>>
>>107920957
you shouldn't need any knowledge of assembly to understand like 95% of what gets posted in these threads. you generally will need a decent understanding of operating systems, though, which might make things difficult for someone in your position
>>
>>107920671
unfortunate, I missed yesterday's thread.
I can't of the top of my head say whether I've used this thread's syscall before, but I had heard of it
>>
>>107909236
>to please post their use case
The only time I've used it was to use the reimplement the basic text console you get on tty3 through tty6 and sometimes tty2 by writing directly to the frame buffer. You had to pass a pointer to struct to set and query the frame buffer, and then mmap'd the entire buffer to write to it directly.
>how do you pronounce ioctl
honestly I've always just pronounced it as "io control", but I like eye octal
>>
>>107920671
How would this compare to copy-on-write of a file descriptor? Or just a plain copy? Feels hackier than it should be tbdesu.
>>
>>107921268
>>how do you pronounce ioctl
The Simpsons has taught me it's "ketarl". I prefer "ai oh cuddle", though.
>>
>>107921331
copied fds retain share state across each other. it's kind of stupid to have file offsets tracked by the kernel anyways. who the hell even uses fseek to hint for a prefetch of that specific block?
>>
>>107920957
my take on it (I'm a noob so beware) syscalls are in a sense language-agnostic functions, part of your operating system, so they are written in whatever language your OS is written in (mostly C I would say, but I'm sure there's more). The thing is, you can write programs in other languages (Go, Rust, C, even Python) to talk to the kernel and use these syscalls.
These syscalls are important because things can go very bad if used improperly. Your Windows Defender, for example, is constantly monitoring if any weird program calls specific syscalls, because that would imply malicious behaviour. I'm not sure if these syscalls are the same in Unix and Windows, I would say Windows copied quite a bit from Unix but there's also big differences (feel free to correct me).

>>107921192
>>107920671
can you guys describe to some degree what you use syscalls for? do you use them at work or just for fun? Would love to know. I'm interested in syscalls because I work in cybersec, and if I want to get better at my job I better start learning these mf'ers.
>>
>>107920957
>an assembly language thread?
not really. It's an assembly language thread the same way C++ or Javascript threads are assembly threads because they all ultimately run on a CPU.
syscalls do need some CPU support and interplay that normal functions don't necessarily require, but you as an end-user really don't need to know about that.

The __NR thingy you see above is a preprocessor naming scheme employed to make sure names don't collide. If you had written
#define __NR....

somewhere yourself, you'd possibly majorly fuck up all kinds of things, so as a general rule you don't define anything with leading double underscored unless you know what you're doing.
oh and "defining" in this context just means that you define the character sequence "__NR_pread64" to be equivalent to 17.
so you write
print(__NR_pread64 + 100)
and it would print out 117.

>>107921530
>do you use them at work or just for fun?
Well, I'm in uni still. But at work I'd be using them very little as I'm head for embedded. Some embedded system are running Linux, but plenty aren't.
So yeah, I'm just using them for fun personal stuff. What are you wondering about in particular?
>>
>>107920957
>>107921614
what I forgot to mention:
#define __NR_pread64            17
does ultimately come back to assembly.
On linux, you call a system call by using the "syscall" instruction, which is the same for all of them. To tell your computer which syscall you want to run you give it a number that uniquely identifies it, and that's the number you see defined there.
>>
>>107921614
>What are you wondering about in particular?
For example, why you would write something using syscalls and not a higher-level function in your higher-level language (Go, Python, JS) that does the same (of course the high-level language ends up doing a syscall, but it's easier for you as a dev to manage high-level languages than go down to the syscall level).
>>
>>107921663
because I don't use such high-level languages. The only ones I use really are C and very limited amounts of Rust.
And as an example, C does have standard library functions to open and interact with files, sure, but my main way of interacting with files is to read them into an array, which is much more sensible to do with mmap once the file gets large enough.
Also, to sensibly load the file you'll have to use fstat to query the file's size, and at that point you might as well read the file with read(2) instead of C's fread.
>>
op here, i'm trans btw
>>
>>107920796
>Hopefully desuarchive has some sort of API to get all those syscall of the day posts.
https://foolfuuka.readthedocs.io/en/latest/code_guide/documentation/api.html
https://desuarchive.org/_/api/chan/search/?boards=g&subject=syscall%20of%20the%20day
>>
>>107921663
Understanding syscalls helps even if you don't call them directly. They're the ground truth that puts hard limits on what your program can do.
writev is a syscall for writing multiple buffers at once. It's often a bit faster than write but it's equivalent to just calling write multiple times.
Rust has a function that wraps writev (write_vectored) but:
- you might not think to look for it unless you know that the syscall exists
- there's a limit on the number of buffers you can write at once, and this effectively limits the performance of the syscall, but you only find out about this by reading syscall documentation and not stdlib documentation
So it pays to learn about it even if you use the wrapper.
Another way to think about it is that it's like how it's sometimes useful to look at the assembly that comes out of your compiler even if you never write any assembly. strace (a program that prints the syscalls a process performs) can be an easy way to figure out what a process is doing.
>>
>>107920671
Potentially (and rarely) saves a seek().
So what?
All software (e.g. databases) already written will either use two file handles, communicate it’s changes to the other threads, and/or use a single thread/process for writing a single file.
In a word, useless slop-conceived vanity api ike openat().

Soon we’ll have individual syscalls for every conceivable sequence of file operations with all their parameters jammed together.
open_at_read_write_close(…
>>
>>107922458
SQLite uses it
>Soon we’ll have individual syscalls for every conceivable sequence of file operations with all their parameters jammed together
You're conceiving of it as two operations jammed together when really it's a more fundamental operation that omits the cursor cruft
>>
>>107920671
I wonder if there's any use case for this where mmap plus memcpy couldn't be used
>>
>>107922619
> SQLite uses
Sqlite is a toy database that came to prominence because firefox used it to store cookies or some shit. Imagine using a SQL database to store a small amount of exact-match, single key,single value map values. Enough retardation went on there that I wouldn’t be surprised if it was the sqlite developers that added it.

Similarly, when MS bought the sybase code, they added fibers to the NT kernel to run transact-sql instead of making it mukti-threaded or using setjmp/longjmp
>>
>>107922735
SQLite is used on every single android phone in the world
>>
>>107922275
>They're the ground truth that puts hard limits on what your program can do.
Not at all. System calls are just code written by the company that made your OS, or in the case of Linux, a random guy. They're not a "ground truth," they're just other people's code.
>>
>>107922735
Postgres also
>>
>>107922458
>Potentially (and rarely) saves a seek().
>All software (e.g. databases) already written will either use two file handles, communicate it’s changes to the other threads, and/or use a single thread/process for writing a single file.
You're looking at it backwards. Your hard drive or SSD is not a tape and there is no "file position" or "seek" because that's not how your computer works. That's a fictional concept. Databases are random access and don't use "file handles" at all.
>>
>>107922774
I have some bad news for you.
Hard drives have a track location and a spinning location that is right under the head. Back when people were smart they would take advantage of that location. They still so.

Also, even on an SSD, the access the storage cells are highly serial, so there is a “current position” component in there as well.
>>
>>107923275
>Hard drives have a track location and a spinning location that is right under the head. Back when people were smart they would take advantage of that location. They still so.
"Seek" doesn't change the head location and reading sequentially doesn't have a "current position." The drive doesn't know anything about files. Files in most file systems aren't even guaranteed to be contiguous. That's why there are defragmenters. This is also unrelated to the "current position" because you can have the same file open multiple times at different "current positions" so it is fictional. It only makes sense for tape drives where the head is actually at one spot and physically seeks forwards and backwards.

>Also, even on an SSD, the access the storage cells are highly serial, so there is a “current position” component in there as well.
It's not related to the "current position" of "file handles." Your SSD probably read or wrote 1000 different things in between reading one "file handle" and the next. It did not do any seeking. Learn how the NVMe, ATA, and SCSI protocols work. You're being confused by a fictitious concept.
>>
>>107923376
> The drive doesn't know anything about files
Correct but you are understanding this backwards.
The OS knows where the logical locations of files are, and the hd drivers and hds know how to address those tracks and sectors.
>>
>>107923376
>Learn how the NVMe, ATA, and SCSI protocols work
do you have a book for this? I learn much better from book. And if anybody wants to, please recommend any books you think are worth spending time on
>>
>>107923376
> Seek" doesn't change the head location
It’s not guaranteed to on, say, small files, but large files where multiple threads are reading random locations in a multi-TB it most certainly will.
This syscall encourages not coordinating those accesses.
Modern access algorithms queue up requests and walk up and down the tracks to service the requests closest to the head.

> “file handles”
Some databases, Oracle, for example, can use a raw partition without regard to filehandles, but the same principles still apply. The system knows the position and acts accordingly for efficient access.
…with no regard for this stupid syscall whatsoever that should have never existed, and doesn’t exist on real unixes such as Solaris and AIX, BSD, MacOSX, or even Windows, or VMS or OS/390.
The linux kernel is a great containment area fir unemployed nerds to fuck around and ruin… I’m all for it.
>>
>>107920957
assembly language is a set of instructions beamed into your processor that map 1:1 to machine language (zeroes and ones) and thus the processor understands them well. syscalls are a bunch of functions your operating system provides so that other programs can communicate and request data, operations and what have you. there are ways to invoke syscalls through assembly by writing specific data do specific registers
>>
>>107920796
hopefully this will suffice https://desuarchive.org/_/search/boards/g.desu.meta/subject/syscall%20of%20the%20day/order/asc/
>>
File: file.png (117 KB, 702x952)
117 KB
117 KB PNG
>>107923896
>real unixes
https://pubs.opengroup.org/onlinepubs/9699919799/functions/pread.html
>Solaris
https://docs.oracle.com/cd/E19109-01/tsolaris8/817-0881/6mglbsom6/index.html
https://smartos.org/man/2/preadv
>AIX
https://www.ibm.com/docs/el/aix/7.2.0?topic=r-read-readx-read64x-readv-readvx-eread-ereadv-pread-preadv-subroutine
>BSD
https://man.freebsd.org/cgi/man.cgi?pread
https://man.openbsd.org/OpenBSD-5.3/read.2
https://man.netbsd.org/pread.2
>MacOSX
https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/pread.2.html
>Windows
You can coerce ReadFile into doing this
>>
>>107874979
I finally found Dennis Ritchie's actual thoughts on mmap
https://www.tuhs.org/Archive/Documentation/OralHistory/transcripts/ritchie.htm
>[...] That was the absolutely crucial distinguishing thing about Multics. And that just didn't, that was just completely out of Unix. Partly because it seemed very hard to do, partly because it required fairly sophisticated hardware that was memory mapping hardware, segmentation hardware that was just not on any of the machines we had. Until just over the last few years has not been available on [inaudible] of machines. Furthermore, particularly in hindsight and to us, or to me anyway, there was some sort of conceptual problems, in that Multics really wanted to make a very uniform view of the world based on these segments in which the paradigm for all activity was all relationship with the file system was to institute operations on segments in memory. But of course that's not really possible because you always have devices of some sort. We have terminals and whatnot. And those just can't work on the same model. We've got to have a different model for dealing with I/O. And so there were various between these two possibilities in Multics. In particular there was a thing called the FSIM, the File System Interface Module, that really made a segment, a memory object look like a device. Then you could treat this memory thing in the same sort of way. In fact they cleaned things up a little bit later. But in the original thing the only way you could deal with very large objects was through this FSIM which, if something was too big to fit into a given segment it would use several of them. [Inaudible]. That was something that was inconvenient to do by hand. At any rate, my view is that even though Unix is usually understood does not have this segmentation notion. It only has an I/O notion.
>>
>>107924344
>If you're going to restrict to one main Paradigm, the one Unix has chosen is more powerful in some sense because in the sense it can apply to objects other than addressable memory. In particular that's how things like pipelines and our current form of interprocess communication and so forth all work. By using this same scheme of doing reads and writes. Usually of course people have begun adding something of the segmentation idea, so called mapped files and so forth. They haven't really made it into any of the standards, probably because they're not really a very portable idea, at least with current hardware. Not all machines can handle the notion. [...]
This is from 1998.
tl;dr he did have a philosophical preference for streams but lack of hardware support forced the issue
>>
>>107924344
>>107924350
is this somehow related to memory virtualization and paging?
>>
>>107924344
The Multics way makes more sense to me.
https://multicians.org/fjcc4.html
>A user may reference data elements in a file explicitly through read and write statements, or implicitly by means of segment addressing. It should be noted here that the word "file" is not being used in the traditional sense (i.e., to specify any input or output device). In the Multics system a file is a linear array of data which is referenced by means of a symbolic name or segment number and a linear index. In general, a user will not know how or on what device a file is stored.

>A Multics file is a segment, and all segments are files.[1,3] Although a file may sometimes be referenced as an input or an output device, only a file can be referenced through segment addressing. For example, a tape or a teletype cannot be referenced as a segment, and therefore cannot be regarded as a file by this definition.
>>
>>107924752
The Multics way makes sense but you definitely want to have unified stream I/O available while memory mapped files are more negotiable
So if the hardware you're developing on doesn't even let you do memory mapping and neither does most other hardware then of course you'll go with streams
>>
>>107924047
> got embarrassingly bitchslapped by the manual
Huh… well…that was interesting.
Is that a posix standard I wonder? I don’t ever remember seeing preads come up in truss or using them, so I assumed it was like openat or some linux-specific contortion.
I apologize profusely and unreservedly.
>>
>>107925177
>Is that a posix standard I wonder
Yea that's the first link. The FreeBSD man page says it showed up in SVR4.
openat is also in POSIX but it looks like Linux got it in 2006, then POSIX got it in 2008, then all the BSDs implemented it after that, so there your story is more plausible.
>>
>>107922011
you're not me, but i am indeed trans lol
shhh
>>
>>107923275
lmao, ssds have like dozens or hundreds of simultaneous io channels, backed by a highly abstracted view of the flash via a controller with its own humongous dram cache. all of this is before the kernel's own io scheduler and libc's own buffers.
>>
>>107924047
>>107925177
>>107925262
That's also proof that the Unix way is wrong. If "everything is a stream" is a good idea, why do Unix systems keep having to add more functions like pread and mmap to bypass it? ioctl also ignores the "Unix philosophy" too.
>>
>>107922011
>>107925687
you dont need to announce your faggotry >>/lgbt/
>>
>>107922669
The usecase is to avoid a SIGBUS if your retard user suddenly unplugs storage.
This is why mmap in Rust can never be safe and I never really though about it that way before, but damn, mmap is an even more misdesigned pile of crap than pipes are.
>>
>>107927808
I used to think mmap() were good for taking a read-only snapshot of a file but turns out MAP_PRIVATE doesn't guarantee that changes made to the file after the mmap call won't be reflected on the mapping. And now this
>The usecase is to avoid a SIGBUS if your retard user suddenly unplugs storage.
wtf man
>>
>>107928134
Don't worry, it gets worse.
https://lwn.net/Articles/860419/
>read-only snapshot of a file
literally impossible on Linux
>>
>>107928206
>literally impossible on Linux
if the file resides on a COW filesystem you can use ioctl_ficlone
>>
>>107928275
A process can modify that file between you opening it using ioctl FICLONE.
Or how about it can ftruncate it between you using fstat and ioctl with FICLONE and then trying to read it?
Until you clone it, it is still accessible, and even then, /proc allows you to see list of fds for any pid and do something with them
>>
File: img-2026-01-21-09-29-59.png (191 KB, 1000x400)
191 KB
191 KB PNG
>>107928288
>>
>>107928298
The only way to have a truly "read only" file on Linux is to have an user who isn't a retard and runs your program as a separate Linux user and your program must not have bugs, that's the only way, no amount of cope and seethe and useless bloated logic you can come up with can change the fact that on Linux, a filesystem is free for all.
>>
>>107928305
>>
>>107922275
>>107921663
I just found out Python has mmap in its standard library that wraps the mmap syscall. Thanks buddy, now I know why I should keep studying these fuckers.
>>
>>107920671
Could you do this one for the next thread? https://lwn.net/Articles/978010/
Thanks bud
>>
>>107928401
oh yeah sys_mseal is still far, iirc this is 6.11+
>>
>>107928469
>sys_mseal is still far, iirc this is 6.11+
what does this mean?
>>
>>107928852
seems pretty obv to me
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8be7258aad44b5e25977a98db136f677fa6f4370
>>
>>107926073
Having general operations that work on everything plus special operations that only work on some things is extremely normal, you're really grasping for straws here. Multics also worked like that.

>>107927808
I'm not sure a SIGBUS would be considered Rust-unsafe. The most immediate problem is that read-only memory can change.
You can for example use this to create a non-UTF-8 &str. Decoding one of those can cause a buffer overread.
use std::{fs::File, io::Write, os::unix::fs::FileExt};

fn main() -> Result<(), Box<dyn std::error::Error>> {
let mut file = File::create("/tmp/yowch")?;
file.write_all(b"UTF-8")?;
let map = unsafe { memmap2::Mmap::map(&File::open("/tmp/yowch")?) }?;
let string = str::from_utf8(&map)?;
for ch in string.chars() {
println!("{ch:?}");
}
let _ = file.write_at(b"\xC2", 4)?;
for ch in string.chars() {
println!("{ch:?}");
}
Ok(())
}

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=c7a0e0d587170a4928541f31e40bd63f
I general it's insta-UB for a value behind a shared reference to change (unless UnsafeCell is involved).

>>107928288
>A process can modify that file between you opening it using ioctl FICLONE.
Does that matter as long as you defer all interesting operations until after the clone? The process could also modify it before you even open it and it would shake out to the same thing.

>>107928852
We're going through the syscalls in order by number. pread64 is number 17, mseal is number 462. There are some gaps but according to the schedule we'll get there in late December.
>>
>>107921656
>On linux, you call a system call by using the "syscall" instruction
On 64-bit x86 you would use the syscall instruction, on 32-bit x86 the most common way was to issue a software interrupt(int 80h); on arm is to do "svc 0". It is architecture dependent

Though POSIX compliant systems do have a "syscall" function that does the same thing but leaves the behind the scenes implementation to the C library.
>>
>>107928912
>Does that matter as long as you defer all interesting operations until after the clone?
Yes it does, because if memory behind a shared reference changing is insta UB, then this whole SIGBUS nonsense is UB and mmap isn't unsafe, it's UB to use.
>>
>>107928945
On 32-bit x86 you'd ask yourself what's the usecase, use ARM or RISC-V at that point.
>>
>>107928946
Well the order of operations would be:
1. Open the file
2. Clone it
3. Map it into memory
Other processes could only modify the file before 2, but it's only UB if it changes after 3, so it's fine. Could wrap a nice safe function around it.
>>
File: meme.jpg (49 KB, 908x186)
49 KB
49 KB JPG
>>107928964
You'd have to completely copy the file into memory, defeating the whole point of using mmap.
The correct defense against such modification is just assumption that program isn't misused.
There's no way to write a program where UB is impossible, you can only hope that a process is isolated in its own user or namespace and no other program can tamper with it.
Despite being ACID, databases cannot do anything about power outages or malware just nuking data, and nobody worries about it, it's just not possible to defend against it if you run your program and malware in a way where malware has permissions to modify your program's files.
>>
>>107928991
>You'd have to completely copy the file into memory
wrong, see >>107928275
>>
>>107929017
And what does that do you drooling retard? Your clone can be modified trivially.
>>
>>107929021
And what does copying the file into memory do you drooling retard? Your memory can be modified trivially.
>>
>>107928991
>You'd have to completely copy the file into memory
The kernel/filesystem can do copy-on-write, that's the point of ficlone. Probably not even supported on ext4 though.

>>107928991
You can mmap a file and close the fd and then it won't show up in /proc/$pid/fd any more but you still have the map.
>>
>>107929029
Process memory can only be modified by root, midwit.
>>107929036
Doesn't prevent the file from being modified and fucking over your program.
>>
>>107929060
Modified how? It doesn't have a path or an fd
>>
>>107929092
The whole point is that any other process can open the file and modify it.
>>
>>107929099
How will they open a file that doesn't have a path or an fd?
>>
>>107929103
Write code and show it to me.
>>
>>107929099
https://man7.org/linux/man-pages/man5/proc.5.html
>Users may not access files and subdirectories inside
>any /proc/pid directories but their own (the /proc/pid
>directories themselves remain visible).
>>
>>107929151
Yes you found the correct part, now understand that it is a problem for a process using mmap.
>>
>>107929156
it's not though
>>
>>107929164
It is, midwit.
>>
>>107929109
OK
use std::{
fs::File,
io,
os::fd::{AsRawFd, FromRawFd},
thread::sleep,
time::Duration,
};

use anyhow::bail;

fn main() -> anyhow::Result<()> {
let src = File::open("btrfs/yowch")?;
let dst = unsafe {
let fd = libc::open(
c"btrfs".as_ptr(),
libc::O_TMPFILE | libc::O_RDWR | libc::O_EXCL,
);
if fd == -1 {
bail!("open: {}", io::Error::last_os_error());
}
File::from_raw_fd(fd)
};
unsafe {
if libc::ioctl(dst.as_raw_fd(), libc::FICLONE, src.as_raw_fd()) == -1 {
bail!("ioctl: {}", io::Error::last_os_error());
}
}
drop(src);
let map = unsafe { memmap2::Mmap::map(&dst) }?;
drop(dst);

let string = str::from_utf8(&map)?;
loop {
for ch in string.chars() {
println!("{ch:?}");
}
sleep(Duration::from_secs(1));
}
}

$ truncate -s 114294784 btrfs-test.img
$ mkfs.btrfs btrfs-test.img
$ sudo mount -o loop btrfs-test.img btrfs
$ sudo chown $(whoami):$(whoami) btrfs/
$ testprog
$ echo "Hi" > btrfs/yowch
$ testprog
Hi
Hi
Hi
Hi
[...]

$ ls /proc/1344942/fd/
0@ 1@ 2@
$ printf 'ab\xC2' > btrfs/yowch

The program still keeps printing "Hi" every second, it doesn't observe src's changes.
And I don't think that even if it keeps the fd you're able to modify it? If I remove drop(dst) to keep it open:
$ ls -l /proc/1346365/fd/4
[...] /proc/1346365/fd/4 -> '[...]/btrfs/#261 (deleted)'
$ printf 'ab\xC2' > /proc/1346365/fd/4
warning: An error occurred while redirecting file '/proc/1346365/fd/4'
open: Permission denied
>>
>>107929236
Still has a race condition for it not being UB.
>>
>>107929236
>btrfs
>>
>>107929273
wrong
>>
>>107929283
Your code is effectively worthless, it hides a bug and you're retarded so you don't even understand the problem.
>>
>>107929295
it's not my code. keep coping, dumb retard.
>>
>>107929273
When would the modification have to happen for this race condition?
It's only UB if it happens after the mmap, but it can only be observed if it happens before the ioctl.

>>107929278
Also supported by some other systems but not ext4 unfortunately.
>>
>>107929302
    let map = unsafe { memmap2::Mmap::map(&dst) }?;
drop(dst);

Any process can race to ftruncate before drop.
>but but there's no malware on my system
Then you don't need to write such defensive code, and if you do, then this can cause UB that's hard to debug.
>>
>>107929312
try reading before posting nonsense
>>
>>107929317
I accept your concession.
>>
>>107929317
reading what exactly?
>>
>>107929312
>Any process can race to ftruncate before drop.
I don't think it can, I got a permission denied when I tried. See the end of my post. I can try breaking it in other ways if you have any ideas.
But even if it did, a Mmap at rest stores the memory as a raw mut pointer + length and not as a shared reference yet so it's only UB after you use the map as a slice for the first time. The worst that could happen is a SIGBUS.
>>
>>107929331
What do you think a race condition means?
>>
>>107929336
>he's still at it
how about you provide a POC?
dumb retard
>>
>>107929347
>Prove to me that I'm not retarded
It is easier for me to just wait until you can prove that you aren't.
>>
>>107929336
I repeat: if another process tries to truncate the fd between mmap and drop() it gets a permission denied error. I tried this by getting rid of the drop() entirely and I got a permission denied error.
$ ls -l /proc/1346365/fd/4
[...] /proc/1346365/fd/4 -> '[...]/btrfs/#261 (deleted)'
$ printf 'ab\xC2' > /proc/1346365/fd/4
warning: An error occurred while redirecting file '/proc/1346365/fd/4'
open: Permission denied

And if the process somehow succeeded in truncating the file then this would not cause a value behind a shared reference to change because the shared reference doesn't exist until after the drop(), it's a raw pointer initially.
>>
>>107929360
It's UB to create references to invalid memory, hope you can figure that part out someday
>b-b-but it is just a SIGBUS, nothing serious
So is SIGSEGV, lmao rusties on suicide watch.
>>
>>107929378
nice poc, dumb retard.
>>
>>107929381
Go argue with rustc devs on implementing a poc for their compiler's semantics, not me, you drooling worthless mouthbreather.
>>
>>107929385
what does rust have to do with making a snapshot of a file on linux?
>>
>>107929391
Get back to me when you find the answer to this because it's not my job to understand for you.
>>
>>107929395
see >>107928275
>>
>>107929378
For the third time, you can't even get it to do a SIGBUS because you can't truncate the file even if you leave the fd open. You get a permission denied error. Can you please acknowledge this?
I can try other operations in that /proc directory if you have any other ideas.
>It's UB to create references to invalid memory
I genuinely don't know if it is, I can't find any statements about it.
The most I can think of in terms of compiler optimization is that the compiler is allowed to reorder reads so that the SIGBUS happens earlier than you'd naïvely expect it to. I don't know if that constitutes UB.
>So is SIGSEGV
A SIGSEGV is the good ending, it's the times you don't get a SIGSEGV that you need to watch out for.
>>
>>107929413
This isn't about /proc, temporary file exists, for a short period of time it can be opened and tampered with.
It's a race condition.
>>
>>107929454
>temporary file exists
wrong
>O_TMPFILE (since Linux 3.11)
> Create an unnamed temporary regular file. The path
> argument specifies a directory; an unnamed inode will be
> created in that directory's filesystem.
keep being a dumb retard, dumb retard.
>>
>>107929468
That's great then, the only problem left to solve is retard user just unplugging a mounted storage.
>>
I found this video a really nice explanation of fork() and execv()
https://www.youtube.com/watch?v=SwIPOf2YAgI
>>
>>107929413
>reorder reads
Or give you phantom reads by turning a conditional read into an unconditional one.
But in general reading memory can have side effects even without mmap games, e.g. by pulling a page out of swap, and I don't know that SIGBUS is more problematic than other side effects. If anyone knows the answer I'm genuinely curious.
>>
>>107929531
non-illiterate people get this information through the comet book. Please stop watching videos by retards who care more about making money on youtube than the tech they are presenting
>>
>>107929661
what's the comet book?
>>
File: comet.png (228 KB, 384x576)
228 KB
228 KB PNG
>>107929847
probably this
>>
>coding thread on a nocoder board
>filled with nocoder posts
lol
>>
>>107929908
show us how it's done



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.