Geth MoarVM: jakebman++ created pull request #1968:
fix a minor typo		 00:38
MoarVM/main: 06c0bcbb7a | (Jake Boeckerman)++ (committed using GitHub Web editor) | src/6model/reprs/NFA.c
fix a minor typo (#1968)
 02:30
04:34 kjp joined 04:36 kjp left, kjp joined
patrickb It is unexpected, that a Native red has the is_unsigned flag set to 0 for a uint8, right? 07:52
*NativeRef 08:14
08:21 librasteve_ joined
timo how are you introspecting it? i've not done much with the unsigned stuff we have in moar 10:45
patrickb just solved it. Annoying off by one on my side 10:48
Which means I have pointers working with varargs now. 10:52
(Remaining bits: testing lots of stuff, Str, CArray, CStruct, ...) 10:53
timo is "pass a struct by value" on your list btw? i had a single library that i was interested in that needed that for a single function :D 11:05
patrickb It is not. but MasterDuke is working on switching the default ffi backend to libffi. 11:13
That will enable us to add struct by value support. 11:14
timo so i've had this weird idea recently, inspired by rakudo sometimes violently exploding when it's running and a "make install" is done: we mmap .moarvm files because we don't need to read their entire contents at once to start using them, and many of them we never fully deserialize thanks to lazy deserialization 11:54
by mmapping the files, we also get to take advantage of multiple processes sharing the memory for the mapped files 11:55
however, if the files get changed on disk, these changes will immediately be reflected in memory of the running processes
we have the runtime bits of rakudo and nqp loaded by name rather than by some kind of hash. that allows this situation to happen that the files are overwritten in place by an install process and the whole thing breaking 11:56
if we use a private mapping, we don't get to share the memory any more, except if there's some kind of memory deduplication thing running?
but some filesystems we have access to on linux have copy-on-write exposed to user space programs by way of "reflinks", aka ioctl FICLONE and FICLONERANGE 11:57
i haven't written the code yet to try this, but someone in #btrfs suggested I can open an fd with O_TMPFILE on the same filesystem the file i'm interested is on and then FICLONE the original file into this temp file 11:58
this will almost always do nothing much, except when some other process changes the file on disk. then we will keep the original contents in our processes, and it will still be shared with all the other processes that opened the "same version" of that file
and when the last program that was holding on to the data quits, the now unreferenced data should just dsiappear because the refcount will drop to 0; TMPFILE files are not held "alive" by the filesystem, so we can't accidentally leak these files either 12:00
might just be a big waste of time, tho 12:10
another way to make this work is to make the runtime moarvm files part of the rakudo-m binary, for which i also have a patch. though if we get the thing to work where we only load either Perl6::* or Raku::*, we'd be wasting file size there 12:11
on the other hand, all those segments of the file aren't loaded eagerly when mapping a binary to memory in order to execute it
lizmat I think this is definitely a case that I've run into 12:17
timo the ficlone ioctl wouldn't be available on macos; not sure if macos has a similar thing we could use 12:21
lizmat otoh, I'm not a typical Raku user 12:24
most production Raku production sites wouldn't be re-precompiling stuff on a regular bases 12:25
*basis
however, from a security point of view, I think it would be a good thing to be able to close a potential attack vector
(changing a file that could influence execution of running programs) 12:26
timo if you have access to those files, an attacker could just replace your precomp files wtih files that do something else though :) 12:30
lizmat yeah, but that would only affect new runs of a program, no? the mmapping would affect already running programs, no ? 12:31
timo right, if we didn't mmap, a change to the file would only impact future runs 12:37
ugexe module loading can occur at runtime, so certainly it could affect a currently executing program 13:42
lizmat also true, but with a much smaller window of opportunity? 13:44
ugexe if you referring to time window, that doesn't really matter. exploits aren't usually done by a hacker hand typing stuff into a byte stream in real time 13:47
lizmat true, ok 13:54
so, we currently do not have a check on whether a bytecode file is actually produced by the associated source-file when we load it, is that correct ?
timo that's right 14:06
it's difficult to make something that actually robustly checks for that
given that we have lots of opportunities to do stuff at compile time, so what comes out of a source file isn't straight-forwardly identifiable 14:07
we can really only kind of rely on the precompiled file to tell us. otherwise we'd be in like, cryptographic signature territory 14:08
lizmat but we do have a check that the file is internally consistent, in the sense that no random bytes have been altered in the file since it was created ? 14:12
timo nothing like that 14:14
we do verify bytecode before we attempt to run it to make sure it's at least marginally sane 14:15
lizmat what type of verification is that ? 14:16
timo referenced lexicals and locals must exist, registers must have the correct type for any op they are used in, targets of goto-like instructions are correct, ops in the bytecode actually exist and their argument types and number are correct, some ops may only appear in a specific sequence, stuff like that 14:21
lizmat is the compiler ID embedded in the bytecode somehow ? 14:24
timo we only do it once when we first encounter a given Frame, but we do keep using the memory mapped area of the file where the bytecode lives without re-checking after the first time
18:33 kjp_ joined 18:37 kjp left, rakkable left, camelia left 19:13 rakkable joined 19:28 camelia joined
librasteve_ rakudoweekly.blog/2025/10/27/2025-...-or-treat/ 19:39
[Coke] anything to get merged post release so we have some time to test it before 2025.11? 19:43
timo only the thing where i made something throw an exception in nqp_nfa_run, but that should never be hit by user code 19:45
[Coke] I meant more PRs that were waiting. I know we rolled one back because it landed close to release 19:55
lizmat I merged that one already again, I believe 20:16
and bumped Rakudo accordingly
yup 74bbe19029bee4befe23
linkable6 (2025-10-19) github.com/rakudo/rakudo/commit/74bbe19029 Bump NQP to get rapidhash v3, MasterDuke++
[Coke] Any other PRs in the queue we should look at? 20:51
lizmat #1962 ? 20:57
#1965
#1946 #1947 20:58
[Coke] 1962 looks straightforward... 21:05
1965 is just for CI, looks fine... 21:06
1946 has a ci failure on mac, but I couldn't find the deets. rerunning.. 21:07
tried to rerun. looks like maybe it was queued but isn't running? 21:08
same with '47 21:09
21:50 librasteve_ left 21:53 librasteve_ joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!