00:31:43 -!- amby has quit (Remote host closed the connection). 02:20:15 [[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 "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 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 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 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 Underload would be similar but worse, because you can mess with the data stack 08:27:31 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 uh, I think I've replied to some old messages from the log 09:18:17 [[Special:Log/newusers]] create * CanonNi * New user account 09:19:47 [[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 [[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 [[LPTA]] https://esolangs.org/w/index.php?diff=164234&oldid=164223 * I am islptng * (+678) 11:52:22 [[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:07:41 Hi 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 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 (although I guess the ideal would be to link to the previous part of the conversation so that people can refresh their memory) 14:51:51 HackEso: logs ais523 14:52:09 i forgot 14:52:15 the logs are linked from the topic but I don't think we have a bot that reads them 14:52:24 we have 14:52:48 i mean. it certainly is expandable. 14:52:48 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:53:01 oh 14:54:39 hm. but the website logs still work. one could link from/to website in case of teambacklogging event :p 14:55:05 is hackeso still hackable 14:55:51 HackEso: ^ls / 14:56:00 HackEso: help 14:56:12 its been a while really 14:57:00 ah. now i read you. 14:57:22 `ls / 14:57:25 bin \ dev \ etc \ hackenv \ lib \ lib64 \ proc \ sbin \ sys \ tmp \ usr 14:57:42 thanks 15:16:40 -!- bongino has quit (Ping timeout: 258 seconds). 15:20:55 -!- molson_ has quit (Quit: Leaving). 15:35:50 `ls -l ~/ 15:35:52 ls: invalid option -- ' ' \ Try 'ls --help' for more information. 15:36:09 `ls ~/ 15:36:11 ls: cannot access '~/': No such file or directory 15:36:18 `ls -l / 15:36:19 ls: invalid option -- ' ' \ Try 'ls --help' for more information. 15:36:56 `pwd 15:36:57 ​/hackenv/tmp 15:39:46 -!- molson has joined. 15:42:21 ``ls -l / 15:42:22 ​`ls? No such file or directory 15:42:27 `` ls -l / 15:42:29 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 there we go, that's how you give commands multiple arguments 15:46:10 `` ls -F 15:46:12 ​🌱* \ 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 `learn The password of the month is Myosotis. 15:57:24 Relearned 'password': The password of the month is Myosotis. 15:58:42 I'm still not entirely sure why we even have a password of the month 15:59:35 It's traditional. :P 16:01:08 also, these days, a test whether HackEso's repo functionality still works 16:01:12 because it's hardly used 16:01:38 Anyway. It serves no real purpose, it really is just something we've mostly kept up for the past 10 years. 16:03:37 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 [[Special:Log/newusers]] create * * New user account 16:38:59 [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=164236&oldid=164232 * * (+310) 16:39:01 [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=164237&oldid=164236 * * (+0) 16:59:29 -!- tromp has joined. 17:09:17 oh yeah, I meant to change that 17:10:23 I'm stupid, I always forget 17:10:52 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:37 `? log 17:11:39 ​#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 well there are large gaps when nobody changed the password, but sure, "mostly kept up" is probably right 17:14:32 b_jonas: you might actually get a small giggle out of https://en.wikipedia.org/wiki/Myosotis (unless you know what that is) 17:17:18 `` du -sh . 17:17:20 43M. 17:23:32 int-e: whoa, it's the password of the month! 17:23:55 I don't look at IRC nearly as much these days. 17:25:03 that seems to happen a lot 17:27:23 I'm on the other side of the Atlantic now, though. Maybe that puts me in the channel's time zone. 17:40:27 `as-encoding jrcxz 1f; 1f: nop 17:40:29 ​{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 `as-encoding jrcxz 1f; 1: nop 17:40:44 e3 00: jrcxz 0x2 \ 90: nop 17:41:17 `as-encoding jecxz 1f; 1: nop 17:41:18 67 e3 00: jecxz 0x3 \ 90: nop 17:41:36 hmm, weird use of prefixes 17:41:38 `as-encoding jcxz 1f; 1: nop 17:41:39 ​{standard input}: Assembler messages: \ {standard input}:1: Error: `jcxz' is not supported in 64-bit mode 17:41:57 it would have been too silly for that one to work with a 66 prefix… 17:57:31 yeah, "not encodable" according to Intel 18:00:16 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…). 18:02:59 Hmm, it is interesting that it uses the address size prefix. 18:05:19 if it used the data size prefix the default size would be 32, with prefixes for 64 and 16 18:06:03 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 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:06 err 18:12:26 intel could've picked either prefix at the time, it was arbitrary 18:12:38 ah right, a 67 prefix in 32-bit code means a 16-bit cx? 18:12:54 yeah 18:13:49 AMD could've picked a different prefix for 64 bit mode but it makes sense that they didn't 18:14:02 right, they probably want to reuse the decoder circuit 18:14:12 it's not like jrcxz is even used much. 18:14:23 or jecxz 18:14:27 -!- Lord_of_Life has quit (Remote host closed the connection). 18:15:21 -!- Lord_of_Life has joined. 18:15:51 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 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 What's the current state of these instructions (jcxz/loop*) being microcoded? 18:18:52 (And thus, slow) 18:20:50 -!- tromp has joined. 18:21:36 I believe jrcxz is fast but loop is microcoded 18:22:28 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 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 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 dec rcx interferes with adcx/adox 18:30:25 (source: Agner's latency table from https://www.agner.org/optimize/) 18:39:00 https://stackoverflow.com/questions/35742570/why-is-the-loop-instruction-slow-couldnt-intel-have-implemented-it-efficiently is interesting too. 18:48:45 [[Che]] https://esolangs.org/w/index.php?diff=164238&oldid=122359 * Cameron * (+30) Made an interpreter 18:49:17 [[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 [[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 "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 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 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 b_jonas: the page containing the code that you're trying to might have been paged out 20:16:58 * trying to jump to 20:17:39 maybe I was misinformed, or maybe there's a reason the processor couldn't jump and then subsequently fault 20:18:27 Or does the GP actually happen *before* IP is updated? 20:18:41 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 (LOOP is actually documented to be able to cause a #GP) 20:19:15 oh, I was looking at JRCXZ 20:19:42 But that *shouldn't* cause an issue either; the limits in question are all available right away, while LOOP executes. 20:19:49 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 but that's different from a #PF 20:21:32 What else is there... hardware interrupts? Surely those can wait until after the instruction is done. 20:22:41 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 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 presumably some sort of race condition due to all the pipelining 20:23:35 I think the #PF claim is bogus. 20:24:02 Or maybe specific to whatever i386 did to handle the related GP issue. 20:24:33 the second answer claims they made it slow intentionally, and speculates about the reasons 20:25:17 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:19 whoa, `as-encoding? 20:33:27 `cat bin/as-encoding 20:33:30 cat: bin/as-encoding: No such file or directory 20:33:36 Oh, right. 20:34:15 `as-encoding jrcxz 1f; 1: nop 20:34:17 e3 00: jrcxz 0x2 \ 90: nop 20:34:18 `asm jrcxz 1f; 1: nop 20:34:20 0: e3 00 jrcxz 0x2 \ 2: 90 nop 20:34:23 Hmm. 20:39:00 `as-encoding xchg eax, eax 20:39:02 ​{standard input}: Assembler messages: \ {standard input}:1: Error: too many memory references for `xchg' 20:39:15 `as-encoding xchg %eax, %eax 20:39:17 87 c0: xchg %eax,%eax 20:39:43 …now I'm wondering whether or not that's the most efficient way to zero the top half of %rax 20:39:47 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 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 (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 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 So the claim is getting more dubious... or well, it points towards intel doing something weird with those instructions. 20:46:12 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 but I'm not immediately sure how you'd determine what happened to cx, upon catching the segfault 20:47:43 I guess you could run it in gdb (which I assume is able to look at noncanonical pointers without crashing) 20:48:09 how much info can you extract with libsigsegv, hmm 20:50:43 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 It appears that Linux doesn't allow us to map that particular page. 20:59:31 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:17 interesting 21:00:36 and you can't get any nearer than 4096 bytes due to the page size 21:00:51 what about if you change the config setting that normally prevents you mmapping over null? 21:01:14 /proc/sys/vm/mmap_min_addr 21:04:47 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 ais523: still denied 21:05:18 -!- ais523 has joined. 21:05:25 pity 21:06:26 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 Though if we can put code at 0 and do a backwards `loop`... hmmm 21:07:34 (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 all-bits-1 is a valid address, though 21:08:13 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:10:53 hmm, right. 21:23:22 huh, apparently some x86-64s have matrix registers in addition to vector registers, now 21:23:41 although they don't do much yet except for matrix multiplication and addition 21:24:31 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 isn't built to handle this combo easily 21:25:12 b_jonas: call/ret both jump and change rsp 21:25:20 but I guess they're probably special-cased 21:26:34 "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 ah, setarch --mmap-page-zero 21:27:49 wait, no 21:28:01 that automatically maps read-only zeros over null, which is not what we want 21:28:05 though I'm not sure that still exist on x86_64; it's mostly for x86_32 running virtual 8086 mode 21:28:46 it had a very promising name though! 21:29:17 I can't see another similar setting in setarch or personality 21:29:19 maybe prctl? 21:30:51 nope, can't see it there either 21:30:54 b_jonas: meh it seemed okay to change on a single-user machine for the purpose of an experiment 21:31:01 I changed it back, of course 21:36:53 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:36:57 so just be root 21:37:20 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 and still no luck at 0x7ffffffff000 21:39:23 :P 21:43:49 I wonder whether maybe there's some technical limitation against mapping that address 21:44:23 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 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 ok, maybe that last part isn't true 21:59:35 I think it's not used as a sentinel value in kernel-user interfaces, only within kernel land and within userland 22:00:04 no wait, it is 22:00:37 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 but that doesn't use 0x7ffffffff000 as a sentinel 22:09:37 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 https://github.com/torvalds/linux/blob/master/Documentation/arch/x86/x86_64/mm.rst calls it a "guard page" 22:10:14 int-e: ooh 22:10:18 both IIUC 22:10:36 (well, the second one is hard to misunderstand) 22:11:02 err, "guard hole" 22:13:18 that said, it isn't immediately clear to me why a non-canonical address in the RSB would be vulnerable 22:13:28 it isn't like an attacker can control memory there! 22:14:24 -!- DOS_User_webchat has joined. 22:15:26 maybe the issue is that the address wraps to a valid address 22:15:30 ais523: but an attacker can control memory at 0x0 22:16:04 yeah, some sort of wrapping would be my guess 22:16:20 anyway, I'm not going to dig further, this is good enough for me :) 22:16:53 (digging further would mean finding the commits surrounding this and then the accompanying LKML discussions) 22:17:54 when you're in a guard hole, stop digging? 22:18:09 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).