[GTALUG] Intel Meltdown Bug -- Conundrum For New Desktop PC Build Spec (to run debian Linux) -- Switch From Intel CPU To AMD CPU ??

[Russell]

I broke this out as a separate response. In part to explain my archaic misuse of terminology.

On 9 January 2018 at 12:23, D. Hugh Redelmeier via talk <talk at gtalug.org> wrote:
> | From: Russell via talk <talk at gtalug.org>
>
> | On January 8, 2018 10:33:00 AM EST, "Steve Petrie, P.Eng. via talk" <talk at gtalug.org> wrote:
>
> | >Intel 4-Core i5-4460 3.2GHz Haswell Processor. (I know, I know, the
> | >Intel Haswell CPU series is obsolete, but let's just ignore this fact
> | >for the present discussion.)
> |
<snip>
> | Certainly this is industry wide and not just within Intel. There are
> | perhaps a couple of singular exceptions to-date.
>
> Yes.
>
> The IC processes are so effective that complexity is cheap.  It is
> really hard to make a complex system secure.  This affects all
> processor manufacturers
>
> | Having a predictive
> | microcode hypervisor has been described as having a RISC backend with a
> | CISC frontend.
>
> I don't think that you are using the word "hypervisor" correctly.  I

I meant hypervisor as the firmware supervisory part in the circuitry. On reading the following it seems to be a historical reference to the kernel itself. I think the term hypervisor is generally agreed to be poorly defined. I apologise if I have furthered that poor definition.

https://en.wikipedia.org/wiki/Hypervisor

> also don't see how "predictive" belongs in this sentence.

Speculative would have been a better choice of words. Branch prediction is the job of the supervisor of the supervisors, in my mind this is the hypervisor.

Interestingly an early example of hypervisioning of machine behaviour, caused a working panel to be struck to discuss memory hotspots. This is not an exact case of what is old becomes new again, but close enough to be interesting to me.

This early example was a single vm hosting a single program. 

https://en.m.wikipedia.org/wiki/SIMMON

Today on Fedora 27, I have an app called boxes, the equivalent hypervisor of an virtually unlimited number of SIMMONS.

It looks to me like whatever will happen with Spectre and Meltdown in the future will shape up to resemble SIMulation MOnitors interrupt mode, with all sorts of attendant discussions, at least until there is some radical movement in core architectures.
>
> | This issue could probably be mitigated by switching
> | entirely to RISC.
>
> I don't know what you mean by "this issue".

I guess I meant the issue that provoked Linus to call out Intel for it's apparent desire to keep selling the public poorly designed shit.

>
> I do think that RISC is simpler and should have fewer cases to get
> right.  But real-world RISC architectures seem to get more complicated
> at quite a pace.

Well CISC certainly broadens the field in application of various modalities, OOP especially. It appears to me that on the software side of any upcoming mitigation, "Retpoline” a/k/a return trampolines, are the gadget descriptors to watch for in the short term. 

In that short term will users, in my case under systemd init and all it's own associated hypervisory schema, be writing our own “per-target” trampoline instructions. This is  not outside the realm of trusted execution. In fact the finer grained a target descriptor requirement is, the more trusted that gadget becomes. Currently it just takes a lot more cycles to solve the problem. 

I use the term trusted, as being adjacent to secure, which is another poorly defined term I sometimes use when talking about this stuff. 
 
https://support.google.com/faqs/answer/7625886

<snip>

>
> In fact, the first news broke because an AMD patch to the kernel
> spilled the beans.  The AMD patch turned off the already present
> mitigation for Meltdown in the case of AMD processors.

I read that post. Has anyone else noticed the lkml.org website is not responding?

> ---
> Talk Mailing List
> talk at gtalug.org
> https://gtalug.org/mailman/listinfo/talk

-- 
Russell