freenode/#sicl - IRC Chatlog
Search
5:21:31
drmeister
Bike: In the paper that you posted (that I got from Steve Blackburn) what are the different yieldpoint methods in Figure 3 describing?
5:22:20
drmeister
I understand the (a) conditional one (I think). But (b) and (c) - I don't see how they work.
5:23:17
no-defun-allowed
Some Java virtual machines cause threads to read or write an address, which causes a segfault, which then gets handled.
5:23:30
Bike
they're explained under "Trap-Based Polling Yieldpoints". Basically, when the yieldpoint is hit it does a meaningless memory operation on some page. When you want the yieldpoint to activate, you protect the page so that memory operations on it cause the system to trigger an interrupt
5:24:16
drmeister
That is faster than a comparison and a branch? I guess the slow path is a lot slower - right?
5:25:46
Bike
I think figure 5 is the one you want. sometimes the traps do much worse but not always.
5:26:22
drmeister
Ok. I should have read the paper again. I was going off the figure 3 that Steve posted in a Zulip post and I needed the paper to decode it.
5:26:42
Bike
though it depends. in the results under "Global Yieldpoints" they get a 2.5% overhead for a conditional, 2.0% for the load trap, and then 36% for the store trap
5:27:40
Bike
that kind of memory trap stuff isn't something i've dealt with before, so i don't know the ins and outs very well, unfortunately
5:27:57
Bike
but my impression is that garbage collectors and stuff have often used these mechanisms
5:29:58
beach
And it is not clear to me what the performance penalty of invoking the operating system would be.
5:36:45
beach
I know I need something like that when the global collector requests its "roots" from the nursery collectors.
5:38:17
Bike
they mention garbage collection, "user-level thread preemption" so i guess interrupt-thread, code patching, "biased locking" which from a quick google is probably irrelevant whatever it is, and profiling.
5:39:18
Bike
the paper is mostly about yieldpoints themselves. doesn't go into the applications too much
5:41:18
Bike
we actually have problems in clasp with thread interrupts. you can only interrupt threads at safe/yield points, which for now are allocations. So if a thread is in a loop that doesn't allocate, you can't interrupt it.
5:41:47
Bike
i suppose cleavir is probably well enough developed now that i could whip up an insertion pass. i know you already wrote some loop detection code
5:44:04
beach
Hmm. I am thinking that one could have a counter on back arcs, so only test the yieldpoint every 100 times or so.
5:45:37
Bike
you could work type inference into it. if the code has (loop for i below n ...) and n is an (integer 0 100) the compiler doesn't bother inserting points.
5:48:34
beach
Here is another idea. Instead of checking at function calls, check at function returns. Then it can be done by modifying return addresses on the stack.
6:35:37
ebrasca
no-defun-allowed: You start in big endian , if you like to change to litle endian you need to run some istructions in big endian.
6:36:53
no-defun-allowed
I see. Wouldn't you decide when the executable starts? Generating code for both big- and little-endian to support both seems silly even for #sicl standards.
6:39:51
no-defun-allowed
If so, you might just keep running in big endian (assuming nothing else requires little endian).
6:43:48
no-defun-allowed
Although stylewarning told me "no one likes big endian" (when I asked about it while porting a Smalltalk implementation to the Wii, which was stupid enough to not do its own endianness conversion when loading images), but evidently the OPAL people like big endian.
6:44:21
no-defun-allowed
I think SICL will be 64-bit only, and I haven't heard of any language implementation which lets you switch between 32-bit and 64-bit code as such.
6:44:53
no-defun-allowed
From memory, one switches between modes on x86-64 by modifying the page table, which has a bit for 32/64-bit code, so clearly only the OS can do that.
6:46:24
no-defun-allowed
From memory, macOS has "fat" binaries which could have both PowerPC and x86, and then AMD64 and AArch64 code, but that selects one architecture at load-time.
6:49:03
no-defun-allowed
Perhaps I need to modify that Smalltalk to do endianness conversion, because I really dislike that one should have to modify the Xerox image to run it on another computer - wasn't the whole point that it was device independent? But I recall that advice came from Xerox, which makes it harder to argue with.
6:49:22
beach
I don't imagine switching between endian-ness, and I am not planning to support 32-bit processors.
7:08:00
beach
It depends on the person. I don't think you know enough about the low-level details of implementing Common Lisp to take on something like compiler optimization or generic dispatch. There is lots of very mundane stuff, but that's too trivial for you, so I don't want to give you that. There is not much in the middle.
7:09:41
no-defun-allowed
The first that comes to mind is a random number generator, because I spent a few weeks writing fast RNGs for simulation.
8:14:35
beach
No, as it turns out, what the Common Lisp HyperSpec thinks of as Environment is something different.
8:18:33
beach
How about you go read the documentation then. That would be quite appropriate for you.
8:27:04
beach
If you forget about that chapter for a second, then the word "environment" in the context of software often means "a mapping from names to objects".
8:27:51
beach
So Clostrum is about mapping names of functions to functions, names of packages to packages, names of classes to classes, names of method combinations to method combinations, names of types to types, names of SETF expanders to SETF expanders, etc.
8:28:47
beach
So you will find functions in Clostrum such as FDEFINITION, FIND-PACKAGE, FIND-CLASS, etc.
9:08:25
frodef
This is how far the linux kernel goes to avoid simple indirect calls: https://www.usenix.org/system/files/atc19-amit.pdf
9:20:33
heisig
Do I understand correctly that most problems related to Spectre are because people want to execute closed-source software from dubious sources on their machines?
9:21:36
no-defun-allowed
You apparently can do it with JavaScript code. It depends if you think the Web is a dubious source...
9:23:19
no-defun-allowed
My policy of disallowing arbitrary network writes with Netfarm hopefully avoids making such an attack useful.
9:24:09
no-defun-allowed
Then you'd have to communicate the data you stole by retrieving objects somehow, and you can't create arbitrary references, so how would you encode anything? Maybe there's a way.
9:27:09
heisig
I just want to make sure that we don't try to solve a social problem (trustworthiness in the digital age) by technical means (retpoline, ...).
9:28:21
heisig
And yes, I consider the web a dubious source. At least while we don't have a reliable infrastructure for managing trustworthiness.
9:29:31
no-defun-allowed
On the other hand, how do you convince a JavaScript engine to generate code to speculatively execute bad code?
9:30:07
no-defun-allowed
Those tend to invent a new kind of exploit every year, or can you do it in correct JS?
9:34:13
no-defun-allowed
(But my approach is pretty mundane, compared to the emerging "alternative" of making one's computer a troff + VT100 emulator.)
9:34:42
heisig
no-defun-allowed: If you allow for arbitrary JavaScript code, the question is more like 'Can you prove that there is no program for which your compiler will ever emit bad code'.
9:35:14
no-defun-allowed
Indeed. I'm now wondering if you can do it without exploiting the compiler though.
9:35:15
heisig
I'm willing to bet the answer to that will always be zero (Unless your compiler is severely restricted).
9:37:02
heisig
shka_: If that were the case, our top computer scientists wouldn't be fighting for us to keep using paper ballots.
9:42:22
beach
Especially since the computer that manages the motherboard is apparently totally insecure.
9:47:38
heisig
But the scariest part is that most people are not ashamed of carrying such crap devices in their pockets.
9:48:07
frodef
Seems to me that Spectre shows that securely running untrusted code in any shape or form is very very difficult.
9:51:07
shka_
frodef: more generally speaking, i would say that "hardware security guarantees" is a flawed concept
10:00:09
beach
I also read an article about how easy it is to install a trap door in a chip immediately before manufacturing, so that not even the chip designer (who will of course outsource the manufacturing to China) knows about it. It would be some simple thing that enables supervisor mode or something like that.
10:01:20
beach
Anyway, I think we have made a mess of our computing environment(s), just as we did with the natural one.
10:18:26
ebrasca
beach: if cpu does have encription modules inside , does it help againt "trap doors"?
10:18:51
no-defun-allowed
There are those "trusted modules" already, but I always wondered how trustable they are.
10:21:42
jackdaniel
I'm sure that hardware companies with roots in USA are very trustworthy, they even have a national agance that ensures the security ;)
10:22:27
jackdaniel
(not to mention that they in fact manufacture in China - another country with high moral standards when it comes to transparency)
10:23:36
beach
ebrasca: I doubt it. There is a bit that tells whether the processor is in supervisor mode. Apparently, it is enough to hook up a capacitor to it. Then it can be enabled by a certain sequence of instructions.
10:26:00
beach
ebrasca: Friendly advice: You should work on your English. It is easy to take people less seriously of they make lots of mistakes.
10:32:06
ebrasca
beach: I am interested in this part "A conforming implementation is free to accommodate other file system features in its pathname representation and provides a parser that can process such specifications in namestrings.".
11:07:58
frodef
The Spectre attack is quite interesting from a runtime perspective. Also the implied focus on indirect branch speed/optimization.
11:12:31
beach
By "from a runtime perspective", do you mean "from the perspective of designing a `runtime' for some language implementation"? Or just "runtime" in general?
11:21:28
pjb
I thought that most problems related to Spectre were that they thought that more money was to be made from extortion and blackmailing (along with slicing spies in two), than by honest capitalist means.
11:31:22
frodef
from a security standpoint, it reveals a flaw in the idea that one can really isolate code by the semi-virtual machine that is "userspace".
11:32:32
frodef
...although this even appears in pure javascript as soon as one isn't very careful about the primitives being made available.
11:34:16
frodef
(the existence of javascript "worker threads" yields high-resolition timers that can be used to extract secret information.)
11:36:10
heisig
My preferred approach to security is to know the developers that wrote my software, to a degree that I could locate them and hit them with a stick.
11:36:31
jackdaniel
OK, then here it goes (sorry heisig!) -- just add arbitrary delays to each operation, i.e (1+ heisig) ; that is 25 nanoseconds
11:36:33
pjb
well, when you see all the side channels that can be exploited for data exfiltration even in air-gapped computers...
11:39:30
pjb
Look at that for example: https://www.securityweek.com/ram-generated-wi-fi-signals-allow-data-exfiltration-air-gapped-systems
11:44:29
frodef
pjb: That seems like a force that could be used for good: Implement wifi without wifi hardware :)
11:59:22
pjb
frodef: theorically. But in practice, there's energy management problems. It's good when you have receiver hardware that can detect low power (RAM level) wifi…
12:00:47
pjb
The thing in this use case, is to be able to transmit data even weakly, using any (limited) resource at hand, but it doesn't restrict the resources you can use to listen to it. You can have a truck of instruments in the road near the building…
12:01:38
frodef
pjb: so you can have a special device in your pocket, run your "special program" on location, and have everything downloading without plugging in a pendrive or anything. Or a truck outside..