Peter Horvath
Entwickler, Linuxer, Vater
- 0 Posts
- 13 Comments
1·3 days ago@davidgro That was a different thing. You can write or read from the physical memory address 0 even on the systems of the today - except that practically all the OS-es are using their paging or memory management to make that address unreeachable. Actually, as far I can remember, on Linux, the addresses between 0 - 65535 are mapped unreachable. If try to write them, you will get SIGSEGV. This is because a memory page is 4K, that is the granularity of the memory permissions. Beside that, we also need SIGSEGV (which would map to a “null pointer dereference” or analog) if it actually tried to access the part of a larger struct (what would be visible as an access to a non-zero, but very small memory address).
C64 had no memory protection, you could read or write anywhere where you wanted. Although it had memory-mapped I/O, meaning that instead of bus-level port communication, all the IO, i.e. communication of the CPU with the chips of the mainboard, happened as if they would be memory. Some chip happily crashed the system on such writes, particularly the CIA did it (general purpose I/O chip and hw clock) for not enough well thought memory operations in the $DC00 - $DFFF range.
You could happily write into 0 on C64. Actually, on the address 1, you could access the chip select pin of some RAM chips, meaning that you could with that switch from the basic ROM into an additional RAM area. Writing to the 0 byte did not had any on the spot visible effect on my experiments, but today I read in the docs, it had actually effect to the GPIO ports related to the memory chips managed at the address 1.
Actually, c64 went even more: the first page, i.e. the addresses between 0-255, very accessible a bit faster, because they required a lesser amount of CPU and data bus cycles. Very important registers, used for important operations, were there.
However, this all is about the C64 hardware. The C64 basic v2.0, which was written by the microsoft, quickly evaporating all my youth nostalgy, had nothing similar to the NULL (of C) or null (of Java). It not even had an “unset”, “undefined” or similar type. The 3 types it had, were: 32-bit floating point, 16-bit integer and 0-254 byte long string.
@misk I think these modchip are exactly what would also really need in the android or iEvil world. Although I am not very sure, how could they be attached into a machine.
@davidgro @hunger Last basic variant I worked with was the basic of the commodore machines. It had no NULL. I have also seen vbscript a little, afaik also it had not.
In Java, null does not mean a real 0 value, I think it is more like a static const, more similar to the None type of the Python. Its name is only a helper for the C/C++ guys to better understand a stack trace.
@misk @Creat It is so terrible. But I believe, hardware jailbreaking should long exist, for example by using raspberry pi-s to attach to the wires of the evil hardware on tricky ways. For example, by attaching pins of the memory chips, their bus could be probably locked for a short time (which is not enough yet for the main OS to crash), and their content could be manipulated. The data structures in the RAM are absolutely not protected against anything. On a Unix-related OS, you can easily find a process data structure by its characteristic signatures, and then you can simply change its UID to 0, voila you are root.
Alternatively, you can simply find the keys used to encrypt the disk content.
Alternatively, also finding the cached blocks in the block cache could be possible. By finding a block, you have access to the decrypted disk blocks, and there you can overwrite against anything, for example by giving a +s to your “su” binary.
@unexposedhazard @cm0002 Linux will be obviously slower. But not intolerably slower.
Reason is simple, much lesser amount of developer resources are there to optimize it. But that is only one of the sides.
Another side: 20 years ago, bottleneck of the 3D gaming was the cpu/gpu. Now we have 1000 times faster machines. What is the bottleneck? Of course, cpu/gpu. Does not stink here something, uhm?
@wltr @canthangmightstain Main obstacle before Linux was the stupidity, 30 years ago exactly like today.
@Butterphinger @RidcullyTheBrown I deeply feel that you are right… but if you say such things, like “walled gardens via client access”, I think you have a brain problem.
Wtf is a “walled gardens via client access”?
@Know_not_Scotty_does If the manufacturer gave linux drivers, they are probably inserted into your linux distribution. So you do not need to install anything.
@victorz @Know_not_Scotty_does “Just install the driver”, so you must have a windows with it, too, only to use your own printer…
@towerful Also you know, it is only matter of time and it will.
@onlinepersona @Innerworld And what do you think, will the AI agent be ready to the following discussion?
@forestbeasts @p4rzivalrp2 Quite honestly, I am a bit disappointed on wayland - it promises a fast X, but it does not provide it. The cause of the slow X was not that it is an old monster, the cause was the much lesser developer resources. Wayland has even much lesser.