00:31:43 -!- amby has quit (Remote host closed the connection).
02:20:15 <esolangs> [[Special:Log/upload]] upload * SzszszszszszszsZ * uploaded "[[File:Onecompiler stdin.png]]": OneCompiler's stdin box, as opposed to interactive consoles
02:56:50 -!- visilii_ has quit (Ping timeout: 258 seconds).
03:32:37 -!- sprout has quit (Ping timeout: 260 seconds).
03:33:09 -!- sprout has joined.
04:09:53 -!- ais523 has quit (Quit: quit).
04:14:23 -!- visilii has joined.
06:38:22 -!- visilii has quit (Read error: Connection reset by peer).
06:38:28 -!- visilii_ has joined.
06:58:27 -!- tromp has joined.
07:59:15 -!- wib_jonas has joined.
08:19:50 <wib_jonas> "you need something like call/cc to interact with the world outside the stack" => I was thinking about this because of Consumer Society, and what I figured that you can restrict the system interaction functions to work only when the data stack is empty, or when the call stack is empty, or even both, but in the latter two cases the system
08:19:50 <wib_jonas> interaction functions need to use continuation passing style so they can call back to your code after they're done, sort of like in Haskell IO. but I don't know how much of that applies to Underload.
08:24:54 <wib_jonas> the problem is that if you want something like Haskell IO, your code effectively returns an algebraic data type that tells what system function to call, plus its arguments including one or more continuation arguments. but if you want to do that in something like pure untyped lambda calculus, then you'd represent the algebraic data type with a
08:24:55 <wib_jonas> simple function (a Church-encoding or whatever it's called), and then that function has the potential to run your code in the system's space.
08:25:21 <wib_jonas> Underload would be similar but worse, because you can mess with the data stack
08:27:31 <wib_jonas> admittedly this is sort of a problem with Consumer Society too, you have to make your code behave properly or else it can mess up the system
08:57:40 <wib_jonas> uh, I think I've replied to some old messages from the log
09:18:17 <esolangs> [[Special:Log/newusers]] create * CanonNi * New user account
09:19:47 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=164232&oldid=164203 * CanonNi * (+195) hi
09:51:11 -!- Sgeo has quit (Read error: Connection reset by peer).
10:46:59 <esolangs> [[Brainfuck]] https://esolangs.org/w/index.php?diff=164233&oldid=164217 * HungKhanh0106 * (+0) /* Batchfile interpreters */ changed link for own impl
11:05:40 -!- amby has joined.
11:11:09 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
11:26:01 -!- tromp has joined.
11:27:26 -!- Lord_of_Life has quit (Ping timeout: 258 seconds).
11:28:22 -!- Lord_of_Life has joined.
11:41:27 <esolangs> [[LPTA]] https://esolangs.org/w/index.php?diff=164234&oldid=164223 * I am islptng * (+678)
11:52:22 <esolangs> [[LPTA]] https://esolangs.org/w/index.php?diff=164235&oldid=164234 * I am islptng * (+515)
11:57:43 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
12:09:05 -!- wib_jonas has quit (Ping timeout: 250 seconds).
12:52:31 -!- tromp has joined.
13:14:40 -!- Lykaina has joined.
13:31:29 -!- bongino has joined.
13:36:31 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
13:47:27 -!- bongino has quit (Quit: leaving).
13:47:44 -!- bongino has joined.
14:27:22 -!- molson_ has joined.
14:27:38 -!- molson has quit (Ping timeout: 256 seconds).
14:35:34 -!- zzo38 has quit (Ping timeout: 256 seconds).
14:42:30 -!- ais523 has joined.
14:43:10 <ais523> <wib_jonas> uh, I think I've replied to some old messages from the log ← I think that too, but it isn't necessarily a bad thing – I can remember enough of the old conversation for it to be reasonable to continue it
14:43:24 <ais523> (although I guess the ideal would be to link to the previous part of the conversation so that people can refresh their memory)
14:52:15 <ais523> the logs are linked from the topic but I don't think we have a bot that reads them
14:52:48 <bongino> i mean. it certainly is expandable.
14:52:48 <ais523> HackEgo used to be able to read them a long time ago but I think that changed for some reason, I'm not sure if its replacement HackEso was ever updated to do that
14:54:39 <bongino> hm. but the website logs still work. one could link from/to website in case of teambacklogging event :p
14:57:25 <HackEso> bin \ dev \ etc \ hackenv \ lib \ lib64 \ proc \ sbin \ sys \ tmp \ usr
15:16:40 -!- bongino has quit (Ping timeout: 258 seconds).
15:20:55 -!- molson_ has quit (Quit: Leaving).
15:35:52 <HackEso> ls: invalid option -- ' ' \ Try 'ls --help' for more information.
15:36:11 <HackEso> ls: cannot access '~/': No such file or directory
15:36:19 <HackEso> ls: invalid option -- ' ' \ Try 'ls --help' for more information.
15:39:46 -!- molson has joined.
15:42:22 <HackEso> `ls? No such file or directory
15:42:29 <HackEso> total 24 \ drwxr-xr-x 2 0 0 4096 Jul 1 2024 bin \ drwxr-xr-x 7 0 0 440 Jul 1 2024 dev \ drwxr-xr-x 3 0 0 0 Sep 1 15:42 etc \ drwxr-xr-x 22 1000 1000 4096 Dec 11 2021 hackenv \ drwxr-xr-x 10 0 0 4096 Nov 17 2019 lib \ drwxr-xr-x 2 0 0 4096 Jul 1 2024 lib64 \ dr-xr-xr-x 34 0 0 0 Sep 1 15:42 proc \ drwxr-xr-x 2 0 0 4096 Jul 1 2024 sbin \ dr-xr-xr-x 11 0 0 0 Sep 1 15:42 sys \ drwxrwxrw
15:42:36 <ais523> there we go, that's how you give commands multiple arguments
15:46:12 <HackEso> 🌱* \ 3 \ a.o \ a.out* \ asmbf-1.2.7/ \ banana.txt \ bef2* \ bfi* \ bin/ \ Burlesque/ \ canary \ cmd.whatis \ compiled_brachylog.pl \ detect* \ detect.c \ egel-master/ \ egel-scripts/ \ egel.zip \ eGtbSgN68aHU \ fence.c \ foo \ he-ng.7z \ he-ng.7z.base64 \ he-ngc* \ he-ngx* \ hlu* \ JoaoDir/ \ just \ karma \ le@ \ nonoodl* \ olist.new* \ output.b \ paste/ \ pd* \ pd.c \ perlV \ pg* \ pg.cxx \ pikhqbow_tst* \ program* \ -.s \ spline \ spout \ sra* \ sr
15:53:07 -!- Lykaina has quit (Quit: Leaving).
15:57:20 <int-e> `learn The password of the month is Myosotis.
15:57:24 <HackEso> Relearned 'password': The password of the month is Myosotis.
15:58:42 <ais523> I'm still not entirely sure why we even have a password of the month
15:59:35 <int-e> It's traditional. :P
16:01:08 <int-e> also, these days, a test whether HackEso's repo functionality still works
16:01:12 <int-e> because it's hardly used
16:01:38 <int-e> Anyway. It serves no real purpose, it really is just something we've mostly kept up for the past 10 years.
16:03:37 <int-e> where "we" is mostly b_jonas and I these days; oerjan and shachaf were prolific potm-ers earlier on.
16:15:43 -!- tromp has joined.
16:26:07 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
16:30:05 <esolangs> [[Special:Log/newusers]] create * * New user account
16:38:59 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=164236&oldid=164232 * * (+310)
16:39:01 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=164237&oldid=164236 * * (+0)
16:59:29 -!- tromp has joined.
17:09:17 <b_jonas> oh yeah, I meant to change that
17:10:23 <b_jonas> I'm stupid, I always forget
17:10:52 <b_jonas> I even checked tom7's blog (radar), which is the other thing I want to do on the internet at the start of each month
17:11:39 <HackEso> #esoteric channel logs: https://esolangs.org/logs/ http://tunes.org/~nef/logs/esoteric/?C=M;O=D http://codu.org/logs/_esoteric/ https://github.com/KrzysztofSzewczyk/esologs/
17:13:47 <b_jonas> well there are large gaps when nobody changed the password, but sure, "mostly kept up" is probably right
17:14:32 <int-e> b_jonas: you might actually get a small giggle out of https://en.wikipedia.org/wiki/Myosotis (unless you know what that is)
17:23:32 <shachaf> int-e: whoa, it's the password of the month!
17:23:55 <shachaf> I don't look at IRC nearly as much these days.
17:25:03 <int-e> that seems to happen a lot
17:27:23 <shachaf> I'm on the other side of the Atlantic now, though. Maybe that puts me in the channel's time zone.
17:40:27 <ais523> `as-encoding jrcxz 1f; 1f: nop
17:40:29 <HackEso> {standard input}: Assembler messages: \ {standard input}:1: Error: junk at end of line, first unrecognized character is `1' \ {standard input}: Error: local label `"1" (instance number 1 of a fb label)' is not defined
17:40:42 <ais523> `as-encoding jrcxz 1f; 1: nop
17:40:44 <HackEso> e3 00: jrcxz 0x2 \ 90: nop
17:41:17 <ais523> `as-encoding jecxz 1f; 1: nop
17:41:18 <HackEso> 67 e3 00: jecxz 0x3 \ 90: nop
17:41:36 <ais523> hmm, weird use of prefixes
17:41:38 <ais523> `as-encoding jcxz 1f; 1: nop
17:41:39 <HackEso> {standard input}: Assembler messages: \ {standard input}:1: Error: `jcxz' is not supported in 64-bit mode
17:41:57 <ais523> it would have been too silly for that one to work with a 66 prefix…
17:57:31 <int-e> yeah, "not encodable" according to Intel
18:00:16 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
18:02:59 <int-e> Hmm, it is interesting that it uses the address size prefix.
18:05:19 <ais523> if it used the data size prefix the default size would be 32, with prefixes for 64 and 16
18:06:03 <ais523> I guess AMD wanted the default to be 64 so they used the address size logic?
18:08:56 -!- zzo38 has joined.
18:11:48 <int-e> ais523: Well, the choice was made by intel when they added the 32 bit mode with i386. I guess they wanted the default to be 32 bits in 32 bit mode.
18:12:26 <int-e> intel could've picked either prefix at the time, it was arbitrary
18:12:38 <ais523> ah right, a 67 prefix in 32-bit code means a 16-bit cx?
18:13:49 <int-e> AMD could've picked a different prefix for 64 bit mode but it makes sense that they didn't
18:14:02 <ais523> right, they probably want to reuse the decoder circuit
18:14:12 <int-e> it's not like jrcxz is even used much.
18:14:27 -!- Lord_of_Life has quit (Remote host closed the connection).
18:15:21 -!- Lord_of_Life has joined.
18:15:51 <ais523> right – Intel suggest that it can be used at the start of a loop to skip past the end if the iteration count is 0
18:16:34 <ais523> but I think most modern compilers don't even bother trying to put the count into cx (perhaps they might use the instruction if it happens to be in cx naturally though?)
18:18:29 <int-e> What's the current state of these instructions (jcxz/loop*) being microcoded?
18:20:50 -!- tromp has joined.
18:21:36 <ais523> I believe jrcxz is fast but loop is microcoded
18:22:28 <ais523> and the reason is that if loop pagefaults on loading in the jump target, the processor doesn't have an easy way to rewind the decrement of rcx, and yet it has to rewind the decrement so that the instruction can be retried after paging the jump target in
18:22:54 <ais523> dec rcx; jnz doesn't have that problem because it can just leave the IP between the dec and the jnz, even though it parses it as a single instruction
18:25:38 <int-e> apparently the answer is... fast on AMD, slow on Intel, though j*cxz is only 2 micro-ops compared to 7 for loop and over 10 for loop(n)e
18:26:15 -!- ais523 has quit (Quit: quit).
18:26:25 <int-e> dec rcx interferes with adcx/adox
18:30:25 <int-e> (source: Agner's latency table from https://www.agner.org/optimize/)
18:39:00 <int-e> https://stackoverflow.com/questions/35742570/why-is-the-loop-instruction-slow-couldnt-intel-have-implemented-it-efficiently is interesting too.
18:48:45 <esolangs> [[Che]] https://esolangs.org/w/index.php?diff=164238&oldid=122359 * Cameron * (+30) Made an interpreter
18:49:17 <esolangs> [[Che]] M https://esolangs.org/w/index.php?diff=164239&oldid=164238 * Cameron * (-2) Messed up formatting
18:49:52 -!- Sgeo has joined.
18:50:36 <esolangs> [[Che]] M https://esolangs.org/w/index.php?diff=164240&oldid=164239 * Cameron * (-2) Added correct tag
19:19:26 -!- lynndotpy60 has joined.
19:19:28 -!- j4cbo_ has joined.
19:19:53 -!- strerror_r has joined.
19:21:00 -!- j4cbo has quit (Ping timeout: 248 seconds).
19:21:00 -!- myname has quit (Ping timeout: 248 seconds).
19:21:00 -!- lynndotpy6 has quit (Read error: Connection reset by peer).
19:21:01 -!- strerror has quit (Ping timeout: 248 seconds).
19:21:01 -!- FireFly has quit (Ping timeout: 248 seconds).
19:21:02 -!- j4cbo_ has changed nick to j4cbo.
19:21:02 -!- lynndotpy60 has changed nick to lynndotpy6.
19:21:23 -!- FireFly has joined.
19:22:29 -!- myname has joined.
19:57:45 <b_jonas> "pagefaults on loading in the jump target" => sorry what? it's always a short jump with the relative offset in the instruction itself. there's no variant where the jump target is loaded from memory.
19:59:08 <b_jonas> I can believe that it's a slow instruction, but not because of that
20:03:42 -!- visilii_ has quit (Ping timeout: 260 seconds).
20:04:10 -!- visilii has joined.
20:14:53 -!- visilii has quit (Read error: Connection reset by peer).
20:15:18 -!- visilii has joined.
20:15:52 -!- ais523 has joined.
20:16:39 <int-e> b_jonas: Yeah, I don't understand that either; those faults would occur when trying to fetch the next instruction after the `loop` has completed and the instruction pointer has been updated.
20:16:41 <ais523> b_jonas: the page containing the code that you're trying to might have been paged out
20:17:39 <ais523> maybe I was misinformed, or maybe there's a reason the processor couldn't jump and then subsequently fault
20:18:27 <int-e> Or does the GP actually happen *before* IP is updated?
20:18:41 <ais523> the documentation says that there's a #GP if the jump target is an impossible address, but doesn't specify a #PF if it's paged out
20:18:47 <int-e> (LOOP is actually documented to be able to cause a #GP)
20:19:15 <ais523> oh, I was looking at JRCXZ
20:19:42 <int-e> But that *shouldn't* cause an issue either; the limits in question are all available right away, while LOOP executes.
20:19:49 <ais523> but LOOP is the same, #GP if the address is not of a valid form for a code pointer, such as being above the last legal virtual address
20:20:31 <ais523> but that's different from a #PF
20:21:32 <int-e> What else is there... hardware interrupts? Surely those can wait until after the instruction is done.
20:22:41 <int-e> TBF, the #GP issue is thorny enough; it means you can't simply treat this as decrement CX followed by a conditional jump internally.
20:23:01 <ais523> the first answer on the page you linked earlier implies that after a successful jump and subsequent #PF, the processor doesn't know whether cx has already been incremented or not
20:23:14 <ais523> presumably some sort of race condition due to all the pipelining
20:23:35 <int-e> I think the #PF claim is bogus.
20:24:02 <int-e> Or maybe specific to whatever i386 did to handle the related GP issue.
20:24:33 <ais523> the second answer claims they made it slow intentionally, and speculates about the reasons
20:25:17 <int-e> The co-evolution of ISA and compilers that is also mentioned is certainly is a factor.
20:28:44 -!- visilii has quit (Read error: Connection reset by peer).
20:30:37 -!- visilii has joined.
20:33:30 <HackEso> cat: bin/as-encoding: No such file or directory
20:34:15 <shachaf> `as-encoding jrcxz 1f; 1: nop
20:34:17 <HackEso> e3 00: jrcxz 0x2 \ 90: nop
20:34:20 <HackEso> 0: e3 00 jrcxz 0x2 \ 2: 90 nop
20:39:00 <ais523> `as-encoding xchg eax, eax
20:39:02 <HackEso> {standard input}: Assembler messages: \ {standard input}:1: Error: too many memory references for `xchg'
20:39:15 <ais523> `as-encoding xchg %eax, %eax
20:39:43 <ais523> …now I'm wondering whether or not that's the most efficient way to zero the top half of %rax
20:39:47 <int-e> Heh, that Intel erratum is also weird. Notably... one of the cases where the contents of CX was supposedly unreliable was a `PUSH` instruction that underflows the stack segment.
20:40:24 <int-e> Rather than, you know, something with a `rep` prefix which would be far more understandable. Or, well, loop*.
20:41:07 -!- visilii has quit (Read error: Connection reset by peer).
20:41:16 <int-e> (It could be the instruction following one of those tricky instructions of course. But it is weird.)
20:43:04 -!- visilii has joined.
20:43:37 <int-e> Oh there's also a comment saying that if you follow the pseudo-code of the LOOP* instructions, *CX is decremented unconditionally, even when #GP is raised.
20:44:17 <int-e> So the claim is getting more dubious... or well, it points towards intel doing something weird with those instructions.
20:46:12 <ais523> so Linux likes to put the stack near but not at the maximum possible usermode address – that means that the #GP should be testable by mapping the highest usermode address and trying to jump into the noncanonical space above
20:46:26 <ais523> but I'm not immediately sure how you'd determine what happened to cx, upon catching the segfault
20:47:43 <ais523> I guess you could run it in gdb (which I assume is able to look at noncanonical pointers without crashing)
20:48:09 <int-e> how much info can you extract with libsigsegv, hmm
20:50:43 <ais523> also I'm not immediately sure whether this would be sigsegv or sigbus – I never really understood the distinction
20:57:36 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
20:58:20 <int-e> It appears that Linux doesn't allow us to map that particular page.
20:59:31 <int-e> this works fine, mmap((void *)(0x800000000000ULL - 0x2000), 0x1000, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON | MAP_FIXED, -1, 0) but not when the 0x2000 is replaced by 0x1000
21:00:36 <ais523> and you can't get any nearer than 4096 bytes due to the page size
21:00:51 <ais523> what about if you change the config setting that normally prevents you mmapping over null?
21:01:14 <ais523> /proc/sys/vm/mmap_min_addr
21:04:47 <ais523> unfortunately it isn't documented in the manpages, and I don't want to decompress the kernel source to check there
21:05:01 -!- ais523 has quit (Quit: sorry about my connection).
21:05:06 <int-e> ais523: still denied
21:05:18 -!- ais523 has joined.
21:06:26 <ais523> I wonder what the motivation for making that page unmappable is? unlike page 0, I can't immediately think of a security reason
21:06:56 <int-e> Though if we can put code at 0 and do a backwards `loop`... hmmm
21:07:34 <ais523> (IIRC the primary but not only reason you can't mmap page 0 is to ensure a #PF if the kernel tries to dereference a null pointer – presumably SMAP would catch most cases of that nowadays but the ban on low mmap is probably older)
21:07:49 <ais523> all-bits-1 is a valid address, though
21:08:13 <ais523> it's a kernel address so you can't normally access it from userspace but that doesn't fit the description of #GP in the docs
21:09:09 -!- tromp has joined.
21:23:22 <ais523> huh, apparently some x86-64s have matrix registers in addition to vector registers, now
21:23:41 <ais523> although they don't do much yet except for matrix multiplication and addition
21:24:31 <b_jonas> ais523: I think the problem is only that an instruction that both outputs to a (non-eflags) register and can jump is unusual so the pipeline isn't built to handle it. both outputting to a register and jumping are tricky super-optimized things that the pipeline handles in a complicated way, and has to be able to roll back when eg. a speculative jump fails, and the register renamer or jump handler just
21:24:37 <b_jonas> isn't built to handle this combo easily
21:25:12 <ais523> b_jonas: call/ret both jump and change rsp
21:25:20 <ais523> but I guess they're probably special-cased
21:26:34 <b_jonas> "change the config setting that normally prevents you mmapping […] /proc/sys/vm/mmap_min_addr" => don't change that in /proc , there's a per-process setting for it
21:27:39 <ais523> ah, setarch --mmap-page-zero
21:28:01 <ais523> that automatically maps read-only zeros over null, which is not what we want
21:28:05 <b_jonas> though I'm not sure that still exist on x86_64; it's mostly for x86_32 running virtual 8086 mode
21:28:46 <ais523> it had a very promising name though!
21:29:17 <ais523> I can't see another similar setting in setarch or personality
21:30:51 <ais523> nope, can't see it there either
21:30:54 <int-e> b_jonas: meh it seemed okay to change on a single-user machine for the purpose of an experiment
21:31:01 <int-e> I changed it back, of course
21:36:53 <b_jonas> int-e: https://man7.org/linux/man-pages/man7/capabilities.7.html CAP_SYS_RAWIO capability lets processes create memory mappings at addresses below the value specified by /proc/sys/vm/mmap_min_addr
21:37:20 <b_jonas> or if you don't like that then create a non-root process that keeps that capability
21:38:55 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
21:39:21 <int-e> and still no luck at 0x7ffffffff000
21:43:49 <ais523> I wonder whether maybe there's some technical limitation against mapping that address
21:44:23 <ais523> but I wouldn't expect it, given that there are plenty of other sentinel values to use, and some recent x86-64 processors on which the address is a valid normal address because there are 57 rather than 48 address bits
21:57:49 <b_jonas> I think it's just a conservative choice as an additional layer of protection against kernel bugs that would handle a zero address wrong, since zero is a convenient sentinel value even for pointers to userspace for the kernel, and in fact it's used as a special value in lots of user-facing interfaces of the kernel too
21:58:58 <b_jonas> ok, maybe that last part isn't true
21:59:35 <b_jonas> I think it's not used as a sentinel value in kernel-user interfaces, only within kernel land and within userland
22:00:37 <b_jonas> mmap without MMAP_FIXED in the flags argument takes the first argument as a hint for where to place the mapping when it's nonzero
22:09:36 <ais523> but that doesn't use 0x7ffffffff000 as a sentinel
22:09:37 <int-e> ais523: https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/hw-vuln/rsb.rst ...this is about preventing having a call instruction at the very end of the canonical user address space, which would put a non-canonical address into the return stack buffer
22:10:07 <int-e> https://github.com/torvalds/linux/blob/master/Documentation/arch/x86/x86_64/mm.rst calls it a "guard page"
22:10:36 <int-e> (well, the second one is hard to misunderstand)
22:13:18 <ais523> that said, it isn't immediately clear to me why a non-canonical address in the RSB would be vulnerable
22:13:28 <ais523> it isn't like an attacker can control memory there!
22:14:24 -!- DOS_User_webchat has joined.
22:15:26 <ais523> maybe the issue is that the address wraps to a valid address
22:15:30 <int-e> ais523: but an attacker can control memory at 0x0
22:16:04 <int-e> yeah, some sort of wrapping would be my guess
22:16:20 <int-e> anyway, I'm not going to dig further, this is good enough for me :)
22:16:53 <int-e> (digging further would mean finding the commits surrounding this and then the accompanying LKML discussions)
22:17:54 <ais523> when you're in a guard hole, stop digging?
22:18:09 <int-e> that does sound like good advice.
22:33:31 -!- DOS_User_webchat has quit (Ping timeout: 250 seconds).
22:38:58 -!- amby has quit (Quit: so long suckers! i rev up my motorcylce and create a huge cloud of smoke. when the cloud dissipates im lying completely dead on the pavement).