Revisiting the Android, UserLAnd app.

One of the facts which I had reported some time ago was, that a handy, easy-to-use Android app exists, which is called ‘UserLAnd‘, and, that I had installed it on my Google Pixel C Tablet. As the tooltip suggests, this is an Android app that will allow people to install a basic Linux system, without requiring ‘root’. Therefore, it mounts the apparent, local Linux file system with ‘proot’ – which is similar in how it works to ‘chroot’, except that ‘proot’ does not require root by the host system to set up – and any attempts to obtain root within this Linux system really fail to change the userid, of the app that the files belong to, or of the processes running. Yet, becoming root within this sandboxed version of Linux will convince Linux, for the purpose of installing or removing packages via ‘apt-get’.

In the meantime, I have uninstalled the ‘UserLAnd’ Linux guest system from my Pixel C Tablet, in order to free up storage. But, I have set up something like this again, on my Samsung Galaxy Tab S6 Tablet, which has 256GB of internal storage. Therefore, I have a few observations to add, about how this app runs under Android 10.

Through no fault of the developer of this Android app, the user is more restricted in what he can run, because Android 10 places new restrictions on regular processes. Specifically, none of the major LISP Interpreters that were designed to run under Debian 10 / Buster will run. (:1) What the Linux developers did was, to make the garbage collection of their LISP Interpreters more aggressive, through a strategy that changes the memory protection bits of memory-maps, to read-only if they belong to the state of the machine, and then, ~to try deleting as much of the bytecode as can still be deleted~. Pardon me, if my oversimplification gets some of it wrong.

Well, Android 10 no longer allows regular apps to change the protected memory state of any pages of RAM, for which reason none of the affected LISP Interpreters will run. And for that reason, neither “Maxima” nor anything that depends on Maxima can be made to run.

Yet, certain other Linux applications, notably “LibreOffice” and “Inkscape”, run just fine… So does “GIMP”…

Screenshot_20200912-171020_VNC Viewer

Also, the way in which files can be shared between theĀ  Android Host and the Linux Guest System has been changed, as the following two screen-shots show:

Screenshot_20200912-155032_VNC Viewer

Screenshot_20200912-155144_File Manager

Here, the file ‘Text-File.txt’ has been shared between Android and Linux. Larger files can also be shared in the same way, and the folder bookmarked under Linux. (:2)

In many ways, the Linux applications behave as described before, with the unfortunate exceptions I just named, and I intend to keep using this app.

Technically, a Host app that just sandboxes a Guest Application in this way, does not count as a Virtual Machine. A real VM allows processes to obtain root within the Guest System, without endangering the Host System. Also, ‘a real VM’ provides binary emulation, that makes no specific assumptions about the Guest System, other than, usually, what CPU is being used. Emulation that includes non-native CPU emulation is still a somewhat special type of emulation.

Therefore, the ability of Debian 10 / Buster to run under ‘UserLAnd’ depends, in this case, on the Linux package maintainers having cross-compiled the packages, to run on an ‘ARM-64′ CPU…

 

(Updated 9/13/2020, 21h30… )

Continue reading Revisiting the Android, UserLAnd app.

Understanding ‘Meltdown’ and ‘Spectre’ in Layman’s Terms

One of the pieces of news which many people have heard recently, but which few people fully understand, is that in Intel chip-sets in particular, but also to a lesser degree in AMD-chip-sets, and even with some ARM (Android) chip-sets, a vulnerability has been discovered by researchers, which comes in two flavors: ‘Meltdown’ and ‘Spectre’. What do these vulnerabilities do?

Well, modern CPUs have a feature which enables them to execute multiple CPU-instructions concurrently. I learned about how this works, when I was taking a System Hardware course some time ago. What happens is meant to make up for the fact that to execute one CISC-Chip instruction, typically takes up considerably more than 1 clock-cycle. So what a CISC-Chip CPU does, is to start execution on instruction 1, but during the very next clock-cycle, to fetch the opcode belonging to instruction 2 already. Instruction 1 is at that point in the 2nd clock-cycle of its own execution. And one clock-cycle later, Opcode 3 gets fetched by the CPU, while instruction 2 is in the 2nd clock-cycle, and instruction 1 is in the 3rd clock-cycle – if their is any – of each of their execution.

This pushes the CISC-Chip CPUs closer to the ideal goal of executing 1 instruction per clock-cycle, even though that ideal is never fully reached. But, because CPU-instructions contain branches, where a condition is tested first, and where, in a roundabout way, if the non-default outcome of this test happens to be true, the program ‘branches off’, to another part within the same program, according to the true logic of the CPU-instructions. The behavior of the CPU under those conditions has also been made more-concurrent, than a first-glance appraisal of the logic might permit.

When a modern CISC-Chip CPU reaches a branching instruction in the program, it will continue to fetch opcodes, and to execute the instructions which immediately follow the conditional test, according to the default assumption of what the outcome of the conditional test is likely to be. But if the test brings about a non-default logical result, which will cause the program to continue in some completely different part within its code, the work which has already been done on the partially-executed instructions is to be discarded, in a way that is not supposed to affect the logical outcome, because program flow will continue at the new address within its code. At that moment, the execution of code no longer benefits from concurrency.

This concurrent execution, of the instructions that immediately follow a conditional test, is called “Speculative Execution”.

The problem is, that Complex Instruction-Set CPUs, are in fact extremely complex in their logic, as well as the fact that their logic has been burned as such, into the transistors – into the hardware – of the CPU itself, and even the highly-skilled Engineers who design CPUs, are not perfect. So we’ve been astounded by how reliably and faithfully actual, physical CPUs execute their intricate logic, apparently without error. But now, for the first time in a long time, an error has been discovered, and it seems to take place across a wide span of CPU-types.

This error has to do with the fact that modern CPUs are multi-featured, and that in addition to having concurrent execution, they also possess Protected Memory, as well as Virtual Memory. Apparently, cleverly-crafted code can exploit Speculative Execution, together with how Virtual Memory works, in order in fact to bypass the feature which is known as Protected Memory.

It is not the assumption of modern computers, that even when a program has been made to run on your computer – or your smart-phone – It would just be allowed ‘to do anything’. Instead, Protected Memory is a feature that blocks user-space programs from accessing memory that does not belong to them. It’s part of the security framework actually built-in to the hardware, that makes up the CPU.

More importantly, user-space programs are never supposed to be able to access kernel memory.

(Updated 01/11/2018 : )

Continue reading Understanding ‘Meltdown’ and ‘Spectre’ in Layman’s Terms