291–294 of 294 posts
Earlier quoted context omitted.
> 4KB/s (basically dialup speed) I guess if "basically" means "takes 10x longer"?
32 kb/s is on the same order of magnitude as dial-up (56 kb/s), not 10x slower. (I don't know if dial-up is still 56 kb/s these days, but that's the speed historically associated with the term.)
Earlier quoted context omitted.
The problem with spectre/meltdown is they don't use standard calls to ask for memory of other processes... that is the vulnerability. If you were do to do per process mitigation it would need to prevent certain process execution flows from happening, because the vulnerability is a problem with the CPU pulling memory from the way speculative execution works. This actually impacts things that are typically protected an…
Yeah, but if you can mitigate per process, you can keep the secrets of trusted code from the eyes of untrusted code by only affecting the performance of the untrusted processes. The way I understand it the "protection cost" would fall on potential attackers, not on potential victims (unless of course they are both, holders of secrets and runners of untrusted code).
For example, a speculative execution vulnerability might exist when there is a string of data in memory that has a memcp pattern, with memory addresses that are valid. To speed up the execution of programs, the processor might proactively read the memory from that memcp pattern because it is sending a command to the memory controller already.
Many of the mitigation techniques are to flush the caches/buffers and be careful about memory reads, which are the precise things that actually take the performance hits. And one of the problems is since they are access patterns, the vulnerabilities can be the html renderer compiled with an application, an SVG rendering library or a mail client.
For example, lets say there are mitigations built into the JS library... if you build a specifically crafted SVG, you could create similar access patterns to get around it. Its a huge cat and mouse game if there aren't OS protections and it only takes a single app to lose your secrets stored in memory.
Earlier quoted context omitted.
> Look at old game consoles (like a regular old PlayStation) and what they were able to render on what today would be laughably slow hardware. They could do it because developers learned the stack inside and out. You're oversimplifying the situation and drawing conclusions from it. The PSX had dedicated hardware for geometry transforms, video decoding, sound processing, and rasterizing. The CPU was used for game logi…
The description sounds more like PS4 than PS2 (maybe PSX was simpler - PS3 is closer to PS4 and "normal" programming). I've seen numerous examples of how involved CPU was in rendering, especially on PS2, due to special units being exposed as MIPS coprocessors. Efficient rendering meant you had to keep the pipelines happy and that could require significant amount of assembly wrangling. I remember reading about how GTA…
The original claim was 3D worked on the PSX because of "efficiency" of the code. While I'm not claiming games on the PSX were inefficient, the hardware was designed specifically to do real-time 3D rendering. It's not like the PSX could only do 3D because everyone somehow had super deep mastery of the system.
To my understanding the PSX was a big change in console development. While consoles always had some dedicated hardware (blitters, audio DSPs, etc), development was a lot of beam racing. There were no frame buffers, code ran as graphics were being drawn to the screen and during the VBI.
The PSX was more like a modern system where you had a CPU and a GPU (albeit fixed function) with an OpenGL-ish drawing model. It was a far more capable 3D machine than PCs of the time that had to do all 3D work on the CPU with no acceleration.
Tomb Raider on the PSX was impressive because the console only cost $300. While I'm sure Tomb Raider on the PSX wasn't inefficiently coded, the design of the PSX console contributed as much to its existence as the code. Quake on the PC on the other hand could only exist because of the developers' deep system mastery pushing generic hardware to its limits (before GPUs were prevalent).
Honestly, I think it's time to reconsider the wisdom of allowing arbitrary untrustable third party executable code to run instantly in the form of things like JavaScript on web pages, instead of just nerf everyone's computer into molasses to prop up an idea that's been bad for the web anyways. I've been of this opinion for a while now, not just because of performance slowdowns and security issues, but also just becau…
The former should absolutely have some kind of security notification similar to installing an app: "this page wants permissions X, Y and Z". You can either accept those permissions and use the app, or decline them and the app can decide whether to just not work or to disable some features that rely on those permissions.
The latter should have an extremely minimal set of features. Probably just the ability to manipulate the DOM. The second it crosses into something as basic as AJAX requests, it now needs a different security context and the user should approve that. It now has the ability to exfiltrate data from your PC.
The blurring of lines between a web page and a web app has been great in many ways, but security on that front just doesn't seem to have moved much.