18 Sep
2015
18 Sep
'15
6:31 a.m.
> Such as every x86 processor since, what, the
Pentium? They're all
> RISC cores (designed for and) running an x86 emulator.
I've been told this more than a few times and read
it in various
places. It always make me wonder, could we not allow a mode in
modern Intel processors that lets us bypass the x86 code
emulation/translation and run "directly on the metal" (if there were
such a thing).
The purpose, of course, would be to gain performance.
Yes...but.
The first objection that occurs to me is that it's reasonably likely
the "underlying RISC core" is not a very good general-purpose machine.
That's what the "(designed for and)" was alluding to: the underlying
machine, to the extent that there is one, is designed for running
exactly one thing, that being the x86 emulator. It would, for example,
not surprise me if it did not have the user/kernel privilege mode
distinction that approximately all OSes depend on these days.
Others have also raised the point that doing this would require the
vendor to document and support the underlying machine. This is only
somewhat true, but it's doubtless at least part of the explanation.
(The documentation probably exists, for internal use if nothing else,
but likely contains things the vendor is unwilling to release. I don't
recall details, but I recall thinking, in reaction to a vendor leak,
that it might have been the vendor wanting to release documentation but
wanting to retain plausible deniability about having done so....)
And, of course, there are probably other forces at work too.
But it's still annoying and disappointing that only the letter agencies
and the black-hat community are competent to rewrite the microcode in
modern peecees. (Well, and the vendors, of course.)
I just recently (mostly-)finished transcribing the VAX architecture
manual into text (I am doing final proofreading before letting the
result out; I'll announce it here once I have it ready). One of the
subsections says
| C.3.1 Publishing Architecture Discrepancies
|
| The Systems Architecture group maintains the lists of known
| architecture discrepancies. These lists are made available to ARG
| members for distribution within their organizations. The lists are
| submitted to publications that are readily accessible to customers if
| the discrepancies are visible to customers. All discrepancies that
| have been waived will be published in the architecture specification,
| either as a note in an appropriate section, or in an appendix for
| waivers.
|
| The single exception is that we will not publish the list of "system
| killers" outside of Digital. All questions about "system killers",
| even ones asking if there are any, will be answered "No Comment". The
| reason for this is to protect customers (from their users) by
| providing absolutely no information on the subject. In addition, this
| "no comment" policy will be published along with the lists of
| architecture discrepancies.
This evidences a vast faith - now shown to be misplaced - in the
inability of the black hats to discover things without DEC's help; the
notion that such a policy _would_ protect customers from their users
depends on DEC being the only source of such information. My point
here is not to reawaken the "full disclosure" question; it's just that
it would not surprise me if -- no, it would surprise me if not -- there
were a component of this attitude in modern CPU vendors' failure to
release documentation on the real hardware, despite all the history
showing that such policies just give the black hats an advantage....
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B