1: Yes, you will eventually need to mmap more memory. Since you want to minimize the number of mmap calls necessary for things like heap allocations, you generally allocate in larger chunks then necessary and then malloc etc. allocates from these chunks. It doesn't matter too much in terms of memory waste, since in the back end, linux allocates physical memory lazily, so the extra allocated block of virtual memory doesn't get a physical allocation until something tries to access it. For this reason, it can sometimes seem like a malloc call completes successfully, but you run into an out of memory condition once you try to actually use your "successfully" allocated memory.
2. It turns out most kernels don't actually enable the NX bit automatically, with the reason given being that early processors have buggy implementations, so by default the NX flag is not honored. As a result, all memory is executable by default, unless explicitly set not to be (i.e. using memprotect), and this is only if the kernel is compiled to support NX, which it may not be. This is changing, and some systems such implementing SELinux or similar are supposedly stricter but I haven't actually tested this out myself.
1. Elaborate more on this, as this doesn't agree with my understanding of it. Glibc Malloc allocates differently depending on the size of the allocation -- glibc uses dynamic mmap thresholds, which as I previously stated starts at 128kb, but when blocks larger than the current threshold are freed, the threshold is adjusted to the size of the freed block, unless once again, you've set any of the slew of paremeters that disable the threshold in which case you'll go back to either "old school" brk() memory management by storing current and previous results of sbrk(0) or you will have arenas for small allocations managed through mmap().
2. If only this were true, I regularly pine for the days of EIP -> 0xc0c0c0c0. It is true that some compilers generate entirely RWE memory pages, but usually for much different reasons (Executable stacks for GCC trampolines, for example)
Not at all. It's saying use standards when there is a standards compliant alternative, because it's both better coding practice and because it means you won't be screwing over your users and you won't be screwing over developers who wish to write alternative implementations.
In this case, the USSD is not the bug. The fact that it can be triggered from HTML and cause a factory reset without user interaction is the bug. At least with older phones, after entry, it was necessary to hit dial before any effect was taken.
That's true, but sort of missing my point. Security bugs are very rarely "security bugs" in isolation. They're far more often unexpected interactions between subsystems. Here, the expectation of the browser is that it can fire a "phone number" Intent securely, because the dialer app will handle it. But the phone number intent also happens to hook to the USSD layer. It's not USSD's "fault", as the check needs to be in the browser according to the architecture. But USSD remains a booby trap because it's an unexpected legacy feature with surprising security behavior.
It'll be interesting to see where the opposition takes their broadband policy. With Turnbull at the helm of opposition telecommunications policy, it is certainly beginning too seem like they are less likely to completely tear down the NBN. Given that it is becoming abundantly clear that something needs to be done, I think it's probably more likely that they will simply change the scale of the project.
At any rate, they seem to have given up on the ridiculous notion that wireless is a suitable replacement in urban areas, and actually seem to be moving towards a more comprehensive plan...
I'm holding out hope that even with an opposition government that in urban areas there will be optical. The question will be how they manage the future of the infrastructure, and whether or not they adequately provide for rural areas.
P.S. If you do invite Woz out for beers, count me in :P
I am curious about the senate committee choosing to single our Microsoft and HP in their attach, when there is ample evidence to suggest that so many other well known companies are engaging in similar practices. In 5 minutes, I came up with articles from major papers documenting 3 of the biggest companies in the US using similar practices...