[Info-vax] Future comparison of optimized VSI x86 compilers vs Linux compilers

[Camiel Vanderhoeven]

Op vrijdag 31 juli 2020 19:37:18 UTC+2 schreef Simon Clubley:
> On 2020-07-31, John Reagan <xyzzy1959 at gmail.com> wrote:
> >
> > tl;dr Our memory model isn't one that you can select on Linux and our optimization will be a work-in-progress.
> >
> 
> When considering memory models and Linux versus VMS performance comparisons
> there is one other thing that absolutely needs to be considered and that is
> the overhead imposed by the mapping of a KESU based OS to an architecture
> which is KU based.
> 
> At the moment, no-one (including VSI based on recent comments) knows how
> much of an overhead this mapping imposes and how bad things might get
> when PCID is not available.

Sure, we don't know exactly, but we're smart enough to make some educated guesses, and there's no reason at al to be concerned about this, certainly not when PCID is available. Maybe the outcome will then be a recommendation not to use processors that don't support PCIDs.

Btw, other OSes on x86 nowadays - post meltdown - switch pagetables when transitioning between ring 0 and ring 3 in the same way we do for 4 modes, lookup KPTI.

> The obvious question to ask is if the overhead is going to be enough,
> especially when PCID isn't available, to justify moving RMS from
> executive mode into kernel mode ?
>
> From a security point of view, RMS code is effectively kernel mode
> code anyway at the moment as you can get from executive mode to kernel
> mode without any additional privileges required.

I'd wish you'd stop spreading this nonsense. Pardon my French. the Exec/Kernel mode line was never intended as a security/privilege related line, its a mechanism that helps stability by protecting kernel mode data/code from bugs in exec mode, it's not meant to protect against malicous code executing in exec mode.

Camiel