Recently posted comments

With lots of ways to do it, from simple zero-width lines to antialiased trapezeoids in X-render. With lots of complicated code which runs in the X-server, with the root privileges. Here's documentation for some of it: http://tronche.com/gui/x/xlib/graphics/

In short, it's been known for ages that the X server is about as holey as Swiss cheese.

X protocol isn't complicated, but only verbose after all these years. I'm waiting to see how Wayland protocol will look like and behave after 20 years...

The same goes for Wayland and Weston.

EVERY major operating system now uses a display server and you may as well complain about DWM or Quartz.

2. ASIDs cannot by definition be cheaper, paging related caches and checks will always require more circuits and cycles than a simple comparator. not sure what address space layout decisions have to do with this though, when you have ASIDs by definition you have full address spaces for each ASID. if you meant mixing different ASIDs in the same virtual address space (how?), then nobody does that.

conceptually ASIDs are indeed more generic except this fact is utterly irrelevant, there isn't a mainstream OS out there that would make use of this ability (i.e., mix user and kernel pages in arbitrary ways in the same address space). in practice everyone simply divides the virtual address space into two parts between userland and the kernel, so simple limit checking would do just fine (vs. checking access rights at every level of the paging hierarchy).

3. ASIDs do have their uses indeed, in fact i would love to have a better mechanism on Intel/AMD CPUs to implement some of my ideas but for simple user/kernel separation a segment limit check has no match.

4. to understand the difference in the security level provided by a segmentation and paging based non-exec/no-access kernel protection scheme we have to consider the attacker's assumed ability. against an arbitrary read and write capability they're equivalent. however this is the ideal attacker model only we use to evaluate theoretical boundaries of protection schemes, in practice we rarely get such bugs and that's exactly where the difference becomes important. in particular, the segmentation based approach can achieve a certain level of self-protection by simply ensuring that the top-level page tables enforce the read-only property on the GDTs whereas doing the same for page tables themselves is much harder - this is the attack surface difference. that said, KERNEXEC (on i386/amd64 so far) does attempt to minimize the exposure of top-level page tables but it's far from being a closed system yet (breaking up kernel large page mappings, tracking virtual aliases, etc have non-negligible performance impact).

5. what has segmentation been designed for then? surely there's only so much you can do with a data or code segment ;). why is it difficult to make it efficient in hardware? and which particular bit (there're many descriptor types)? why would paging related data structures be easier to handle in hw than segmentation ones? and how do you imagine beating a simple comparator? so far you haven't offered any facts to make me think otherwise.

The problems stem from bugs in the client libraries used to manage the complex protocol.

Remote X has never worked right and yet we all must endure security vulnerabilities because of irrational desires for stuff that doesn't provide any benefit.

BTW, if you do run the 3.9 kernel, don't expect things like the lcd to work. You'll have to either add a USB network dongle (for ssh) or solder wires to the UART pads.

In the UK we have a neat way of dealing with that. The limited liability that protects shareholders and officers explicitly does NOT cover being "an extension of the directors' will". Which would most certainly cover a troll corporation created to sue but have no assets in the event they lost. No veil, and directors and shareholders become personally liable for the corporation's debts ...

(In UK legalese, "director" can mean anybody with the authority to give orders, ie "to direct".)

Cheers,
Wol

The increasing spread of javascript makes me shudder generally (and so it should - it means there's a far greater likelihood of me having to work closely with it even more).

That's not a rebuttal to your claim, but to the more general anti-bzr opinion, which is fine to have.