rwessel (robertwessel.delete@this.yahoo.com) on February 5, 2018 3:57 pm wrote:
> anon (spam.delete.delete@this.this.spam.com) on February 5, 2018 11:16 am wrote:
> > dmcq (dmcq.delete@this.fano.co.uk) on February 5, 2018 10:24 am wrote:
> > > anon (spam.delete.delete@this.this.spam.com) on February 5, 2018 8:39 am wrote:
> > > > dmcq (dmcq.delete@this.fano.co.uk) on February 5, 2018 6:46 am wrote:
> > > > > Ray Terry (rterry.delete@this.example.edu) on February 4, 2018 7:33 pm wrote:
> > > > > > Ronald Maas (ronaldjmaas.delete@this.gmail.com) on January 17, 2018 11:51 am wrote:
> > > > > > > Spectre may be more difficult to mitigate. But an essential ingredient for a successful Spectre
> > > > > > > attack is the ability of an adversary process to manipulate the branch predictor so it speculative
> > > > > > > executes arbitrary code fragments in the context of a victim process. This manipulation can be
> > > > > > > mitigated by including ASID + privilege level bits into any table lookups done by the branch predictor
> > > > > > > (as pointed out by several people in this thread). In addition the OS should perform a (partial)
> > > > > > > flush of the BTB during context switch in case multiple processes share an ASID. E.g. when system
> > > > > > > is running more active processes than the number of available ASID values.
> > > > > > >
> > > > > > > Now with checking on ASID + privilege level bits in place, the only vector of attack remaining
> > > > > > > for Spectre is within the same address space. This is something that hopefully can be addressed
> > > > > > > within each application. E.g. proper sandboxing of any untrusted code.
> > > > > >
> > > > > > The problem is that same address space is not only a realistic attack,
> > > > > > it's the easiest form, and the one in the original Spectre PoC.
> > > > > >
> > > > > > Spectre makes software sandboxing much harder. We thought we had sandboxed VMs figured
> > > > > > out, and are using them extensively in the form of client-side Javascript and kernel
> > > > > > (e)BPF. (I'm sure there are other examples, but those are the biggies.)
> > > > > >
> > > > > > And although it's primarily a software issues (since only software even knows where the sandbox
> > > > > > boundary is) hardware has to provide the basic ingredients out of which software can build a non-leaking
> > > > > > sandbox. Right now, it's not even 100% clear what those are. A faster or tweaked LFENCE?
> > > > >
> > > > > I don't see fences as a solution. We need to turn the Spectre problem into a Meltdown type problem
> > > > > which means having a new privilege level or a different process or new permissions on the pages.
> > > > >
> > > >
> > > > I'm not sure what you mean. Spectre v2 can be solved by using existing privilege levels and
> > > > simply seperating the predictions for different processes and different privilege levels.
> > > >
> > > > Spectre v1 would require different privilege levels within the same process, possibly with very rapid
> > > > switching between them. It would be awkward in hardware and there is no OS support for it either.
> > > > Adding an instruction that is actually meant for serialization seems more useful to fix
> > > > potentially existing similar exploits that can't be fixed as easily as bounds checks.
> > >
> > > And turning a Spectre problem into a Meltdown one requires different privileges. Without hardware
> > > changes running a JavaScript task within a current process where it can access things it shouldn't
> > > be able to is a pretty big ask. One can put in fences but that makes the code slower and it will
> > > always be a software solution and we'd be waiting for hackers to get round it or find bugs in the
> > > implementation. The question is how to keep the performance and improve the security.
> > >
> > > > I mean if you want seperate permissions for every single javascript script page
> > > > tables will have to be redesigned completely and thanks to Meltdown checking it
> > > > in the TLB will be on the critical path. Doesn't seem like a good idea to me.
> > >
> > > Yes if you want different JavaScript scripts within a single process not be able to access
> > > each others data then that can't be done with a straightforward change to page tables. I was
> > > only considering the case of a single unsafe state in a process. That certainly does make
> > > things more difficult. Checking at the same place as for Meltdown is the obvious way to stop
> > > all the problems but that requires there to be some privilege that can be checked for.
> >
> > Well if you only want a single unsafe state per process then you have to split your processes anyway.
> > We can already do that.
> >
> > One extra privilege level (or two if we combine it with the user/supervisor bit) wouldn't be that
> > difficult to implement but it would still end up being very awkward. You do not want to let a process
> > that runs untrusted code mess with the page tables so all of that needs to go through the OS.
> >
> > There are a lot of things that would be nice to have, but won't be added because no one actually
> > needs them to make software work, so there is no incentive to add them to the hardware.
> > I'm pretty sure if we wanted we could play stupid games with
> > ring 1/2 and segments to get isolation within a process.
>
>
> FWIW, Z has implemented such a facility for years (the uninformatively named "Storage-Protection-Override
> Control"), allowing two protection domains within an address space. This was added for CICS (and a few
> other subsystems), which executed code for transactions in the same address space as the subsystem itself.
> Somewhat simplified, Z has a protection key on each physical page (in addition to what happens with the
> page tables), and the key of the page being accessed has to match the key set in the PSW. CICS will allocate
> storage for the transactions in key 9 (it does require some help from the OS for that), and uses key 8 storage
> for itself. CICS switches to key 9 when dispatching transaction (user) code (which it can do via an instruction,
> without OS intervention, once the OS sets up the proper mask allowing that).
>
> Obviously you'd do a purely page-table based approach for any other systems (storage keys have
> existed since the S/360, when the pre-virtual memory OS's provided a SAS-like view of the world,
> and used those storage keys to protect programs from each other, and so were some-what natural
> to reuse for this purpose), but there is some operational precedent for a facility like that.

Thanks for that. I really should study IBM mainframes more, They probably say, oh that old problem about lots of things that people think are new. :) I wonder what the world would be like today if the PC had been an IBM 370 compatible rather than using Intel x86. No chance of them selling the chips to other manufacturers so they wouldn't have created a market so it wouldn't have happened I guess.