Gibson's Meltdown/Spectre Tester

https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.
--
Peter.
The gods will stay away
whilst religions hold sway

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ???
LOL. Maybe he inserted a couple of #pragma and
20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would
do that (we had such a kook at work).

So the utility did tell me something. I tried a VM first,
and it turns out, VMs don't allow the "true" microcode state
to be seen by the Guest. Good ole VirtualBox tells my
VM the processor is running microcode 18, instead of the 2a
I know it is running.

Since the Host OS was Linux (the only OS which will load
the Jan.8, 2018 microcode for me), I then ran inspectre.exe
under wine.

wine inspectre.exe

And this is the result. Even though it's WINE and runs
the risk of nor handling all OS calls properly, the
green text in the window seems to indicate that Gibson
can see the CPU is running 2a.

https://s18.postimg.org/tv0ythypl/in...under_wine.gif

I don't think WINE has a particularly strong "personality",
and Gibson didn't say it was WinXP or anything. The WINE
registry settings probably don't reflect any of this
current nonsense, so the tool concludes I'm completely
vulnerable.

And if I boot a Windows disk and run the program "native",
I'm not going to get that green text, because Windows won't
load the microcode like Linux is doing at the moment.

My conclusion at the moment is "we can't have nice things" :-)
For some value of green text.

Paul

On Wed, 17 Jan 2018 06:28:20 -0500, Paul wrote:

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ???
LOL. Maybe he inserted a couple of #pragma and
20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would
do that (we had such a kook at work).

Steve is exactly that sort of kook, but mostly harmless. He's been
boasting of writing assembly language Windows apps for 25 years or so,
and I've not seen anyone do a disassembly and deny that it's
handcrafted. He is a loon.

Cheers - Jaimie
--
If you mean 'am I serious about what I do', the answer is yes.
If you mean 'am I serious about how I do it', the answer is no.

On Wed, 17 Jan 2018 13:24:40 +0000, Jaimie Vandenbergh wrote:

On Wed, 17 Jan 2018 06:28:20 -0500, Paul wrote:

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ??? LOL. Maybe he inserted a
couple of #pragma and 20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would do that (we had such a
kook at work).

Steve is exactly that sort of kook, but mostly harmless. He's been
boasting of writing assembly language Windows apps for 25 years or so,
and I've not seen anyone do a disassembly and deny that it's
handcrafted. He is a loon.

Cheers - Jaimie

When you look at a program in memory you will see a sequence of one's and
zeroes. The software you might use to examine this mess kindly arranges
the output to be more understandable by humans, generally by translating
into assembly language or maybe something else. I don't know how one
could determine in what language the author wrote the program, but
whatever it was, it simply translated into assembly language which in
turn generated a bunch of one's and zeroes.
We used to have guys who would analyze memory dumps generated by a user
after some sort of program crash. These guys had the patience of Job, but
the key to navigation was looking at system calls. It ain't easy.
By the way, what's wrong with assembly language. It's not that bad and
people that do it on a regular basis keep a copy of commonly used
routines like generating output so they don't have to re-invent the wheel
each time.
I use a very powerful text editor - Vedit, which supposedly was first
written in assembly language prior to windows. Not sure what they use for
the windows version but it's very powerful and fast. I started using it
years ago when brief and others were around, Vedit outlives them all.
I wonder what language was used for emacs, that's been around forever
also.

In article , says...

On Wed, 17 Jan 2018 13:24:40 +0000, Jaimie Vandenbergh wrote:

On Wed, 17 Jan 2018 06:28:20 -0500, Paul wrote:

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ??? LOL. Maybe he inserted a
couple of #pragma and 20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would do that (we had such a
kook at work).

Steve is exactly that sort of kook, but mostly harmless. He's been
boasting of writing assembly language Windows apps for 25 years or so,
and I've not seen anyone do a disassembly and deny that it's
handcrafted. He is a loon.

Cheers - Jaimie

When you look at a program in memory you will see a sequence of one's and
zeroes. The software you might use to examine this mess kindly arranges
the output to be more understandable by humans, generally by translating
into assembly language or maybe something else. I don't know how one
could determine in what language the author wrote the program, but
whatever it was, it simply translated into assembly language which in
turn generated a bunch of one's and zeroes.
We used to have guys who would analyze memory dumps generated by a user
after some sort of program crash. These guys had the patience of Job, but
the key to navigation was looking at system calls. It ain't easy.
By the way, what's wrong with assembly language. It's not that bad and
people that do it on a regular basis keep a copy of commonly used
routines like generating output so they don't have to re-invent the wheel
each time.
I use a very powerful text editor - Vedit, which supposedly was first
written in assembly language prior to windows. Not sure what they use for
the windows version but it's very powerful and fast. I started using it
years ago when brief and others were around, Vedit outlives them all.
I wonder what language was used for emacs, that's been around forever
also.

When I programmed for a living I used assembler for a number of various
cpu's not all of them Intel. Mind you the programs tended to be small
usually less than 8Kb or so (embedded chip stuff) but I always liked the
"control" one had over basically everything. C/C++ and Pascal/Delphi is
also used a lot and I have to say I preferred Pascal way more than C. In
fact first 100,000 soucre code lines of code I wrote for Windows was in
straight Pascal without using any libraries, instead making all calls to
Win API's directly. That was very satisfying. I stopped prgramming about
time all this "new crap" starting appearing, e.g. Net, C#, Perl, Java
etc. and to be truthfull glad I did as I hate the thought of having to
write anything uses the web (too used to writing own code to
commmunicate directly me thinks .

In article , Pjp
wrote:
When I programmed for a living I used assembler for a number of
various cpu's not all of them Intel. Mind you the programs tended
to be small usually less than 8Kb or so (embedded chip stuff) but
I always liked the "control" one had over basically everything.

I know what you mean ... and that's fine for microcontrollers and simple
CPUs. Modern mainstream CPUs use techniques like multiple pipelines
running in parallel and out-of-order execution (the same techniques, as
it happens, that make Meltdown and Spectre possible) to squeeze the last
possible ounce of performance out of the silicon, and there's less
control -- and less point in trying to code at the low level -- than
there used to be.

In fact first 100,000 soucre code lines of code I wrote for Windows
was in straight Pascal without using any libraries, instead making
all calls to Win API's directly. That was very satisfying.

The same sort of satisfaction that you might derive from beating yourself
over the head repeatedly with a brick?

Libraries make life easier. It may be more fun if you write your own
libraries, but eschewing them is just masochism.

I stopped prgramming about time all this "new crap" starting
appearing, e.g. Net, C#, Perl, Java etc. and to be truthfull glad
I did as I hate the thought of having to write anything uses the web

Perl has been around for longer than you might imagine! Certainly a lot
longer than Java or .NET.

--
Cheers,
Daniel.

In message , Dave
writes:
On Wed, 17 Jan 2018 13:24:40 +0000, Jaimie Vandenbergh wrote:

On Wed, 17 Jan 2018 06:28:20 -0500, Paul wrote:

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ??? LOL. Maybe he inserted a
couple of #pragma and 20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would do that (we had such a
kook at work).

Steve is exactly that sort of kook, but mostly harmless. He's been
boasting of writing assembly language Windows apps for 25 years or so,
and I've not seen anyone do a disassembly and deny that it's
handcrafted. He is a loon.

Cheers - Jaimie

When you look at a program in memory you will see a sequence of one's and
zeroes. The software you might use to examine this mess kindly arranges
the output to be more understandable by humans, generally by translating
into assembly language or maybe something else. I don't know how one
could determine in what language the author wrote the program, but
whatever it was, it simply translated into assembly language which in
turn generated a bunch of one's and zeroes.

On the whole, a person moderately experienced in examining .exe files
can usually tell at least whether they were written in high-level
language or lower, unless there has been a deliberate attempt at
obfuscation. A skilled such person can often make a fairly good guess
_which_ high-level language - C, etcetera.

We used to have guys who would analyze memory dumps generated by a user
after some sort of program crash. These guys had the patience of Job, but
the key to navigation was looking at system calls. It ain't easy.

Probably based on knowledge of how the software in use used memory (or
at least how it created these "memory dumps").

By the way, what's wrong with assembly language. It's not that bad and
people that do it on a regular basis keep a copy of commonly used
routines like generating output so they don't have to re-invent the wheel
each time.

Nothing at all: it produces the smallest, fastest, code. The only
disadvantage is that coding can be more of an effort (and that can be a
significant disadvantage), especially if the code has to work in
assorted environments.
[]
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"This situation absolutely requires a really futile and stoopid gesture be done
on somebody's part." "We're just the guys to do it." Eric "Otter" Stratton (Tim
Matheson) and John "Bluto" Blutarsky (John Belushi) - N. L's Animal House
(1978)

"J. P. Gilliver (John)" wrote

| On the whole, a person moderately experienced in examining .exe files
| can usually tell at least whether they were written in high-level
| language or lower, unless there has been a deliberate attempt at
| obfuscation. A skilled such person can often make a fairly good guess
| _which_ high-level language - C, etcetera.
|

That would depend. A basic compiled executable
(as opposed to .Net, Java, scripting, etc) is compiled
to native or machine code -- the actual CPU operations.
Assembly is just closer to that than higher-level
languages. But I don't see any reason to expect it
would make radically different native code. Maybe
a very sophisticated expert could make some
assessment by studying the native code,
but in general I think the only way you'd know
would be from things like the string table, import
table, etc. For instance, if it has a dependency on
msvcrt.dll then it's probably written in VC++6.
Similarly, each version of Visual C++ has its own
runtime. But in general it's not obvious.

Looking at inspectre.exe, it contains a digital
signature and it's marked as compressed with UPX.
Decompressing and reading the bytes indicates
that there's embedded RTF text that gets loaded
into a RichEdit window. Not likely to be done with
assembly. Even if it's possible it wouldn't make
sense.

Looking at it in Depends shows a lot of calls
to high-level API functions. (That' a handy
program that may be available in the Win SDK.
Depends shows, to some extent, the libraries
and functions used by an EXE.)

Either way, I trust that Steve Gibson knows
what he's doing.

On 17/01/2018 18:20, J. P. Gilliver (John) wrote:
it produces the smallest, fastest, code.

Old assembler programmer here.

Although in theory you can produce better code in assembler, in practice
modern compilers will do all sorts of evil tricks to make things go
faster. Like random use of registers, keeping stores well before loads
of the same data to stop pipeline stalls, laying things out to suit
cache lines, to name but a few.

It was OK on the 8086 (5 word prefech queue IIRC, no cache), but these
days I can't keep the knowledge of all the different blocks in my head,
and still think about the program. C is almost always fast enough. C++
makes more reliable programs, and it's usually fast enough too...

Andy

Jaimie Vandenbergh wrote:

On Wed, 17 Jan 2018 06:28:20 -0500, Paul wrote:

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ???
LOL. Maybe he inserted a couple of #pragma and
20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would
do that (we had such a kook at work).

Steve is exactly that sort of kook, but mostly harmless. He's been
boasting of writing assembly language Windows apps for 25 years or so,
and I've not seen anyone do a disassembly and deny that it's
handcrafted. He is a loon.

Cheers - Jaimie

From a very quick glance using a hex editor, my guess is there is some
code for the GUI portion of his "program" but the program that is what
is actually getting delivered to do the testing is in assembler. Gibson
has been coding in assembler for something like 30+ years.

About the only assembly that I do anymore is inline C. Way back 30
years ago, yeah, I did assembler, too, on mainframes where I can to know
the instruction set and which fields changed position, got extended, or
supplanted depending on the instruction. Gladly I moved on to higher
languages because I did not have to test, debug, and workaround at that
low level anymore.

On 17/01/2018 in message Paul wrote:

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ???
LOL. Maybe he inserted a couple of #pragma and
20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would
do that (we had such a kook at work).

He is (or perhaps was) very well known for writing Windows apps in
assembler and offered a complete toolkit free. I had a play with it and it
produced incredibly fast programs.

--
Jeff Gaines Wiltshire UK
If you ever find something you like buy a lifetime supply because they
will stop making it

In article , lid says...

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ???
LOL. Maybe he inserted a couple of #pragma and
20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would
do that (we had such a kook at work).


No for years I believe he's written most if not all his apps in
assembler, why they're so small for wehat they do. Least years ago he
did.

So the utility did tell me something. I tried a VM first,
and it turns out, VMs don't allow the "true" microcode state
to be seen by the Guest. Good ole VirtualBox tells my
VM the processor is running microcode 18, instead of the 2a
I know it is running.

Since the Host OS was Linux (the only OS which will load
the Jan.8, 2018 microcode for me), I then ran inspectre.exe
under wine.

wine inspectre.exe

And this is the result. Even though it's WINE and runs
the risk of nor handling all OS calls properly, the
green text in the window seems to indicate that Gibson
can see the CPU is running 2a.

https://s18.postimg.org/tv0ythypl/in...under_wine.gif

I don't think WINE has a particularly strong "personality",
and Gibson didn't say it was WinXP or anything. The WINE
registry settings probably don't reflect any of this
current nonsense, so the tool concludes I'm completely
vulnerable.

And if I boot a Windows disk and run the program "native",
I'm not going to get that green text, because Windows won't
load the microcode like Linux is doing at the moment.

My conclusion at the moment is "we can't have nice things" :-)
For some value of green text.

Paul

On Wed, 17 Jan 2018 06:28:20 -0500, Paul
wrote:

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ???
LOL. Maybe he inserted a couple of #pragma and
20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would
do that (we had such a kook at work).
Gibson does write in assembler. I think, however, that
he uses a macro assembler.

I went to grad school in the 1960s. Peter B. Olson
was an undergraduate at the same school who wrote
IBM 360 code in assembler, including a spool program,
and a job submittal program that ran from APL so that
people no longer needed to use card decks.

For a couple of years he did not use macros, which
he as able to do since he know all of the SVC calling
sequences the he used by heart. Yes, he could
write programs using the console data switches in addition
to merely debugging at the console.

I don't remember why he didn't use macros; perhaps it
was because he thought it took too long for the assembler
to process them on our 360/50. However, he switched to using
macros, for the SVC's at least, when IBM changed the way
that one or more SVC's worked and he had go through all of
his code to fix the calls that had to change.

(I think this is the same Peter B. Olson who worked at
the Free Software Foundation and who died in April 2017.)

So the utility did tell me something. I tried a VM first,
and it turns out, VMs don't allow the "true" microcode state
to be seen by the Guest. Good ole VirtualBox tells my
VM the processor is running microcode 18, instead of the 2a
I know it is running.

Since the Host OS was Linux (the only OS which will load
the Jan.8, 2018 microcode for me), I then ran inspectre.exe
under wine.

wine inspectre.exe

And this is the result. Even though it's WINE and runs
the risk of nor handling all OS calls properly, the
green text in the window seems to indicate that Gibson
can see the CPU is running 2a.

https://s18.postimg.org/tv0ythypl/in...under_wine.gif

I don't think WINE has a particularly strong "personality",
and Gibson didn't say it was WinXP or anything. The WINE
registry settings probably don't reflect any of this
current nonsense, so the tool concludes I'm completely
vulnerable.

And if I boot a Windows disk and run the program "native",
I'm not going to get that green text, because Windows won't
load the microcode like Linux is doing at the moment.

My conclusion at the moment is "we can't have nice things" :-)
For some value of green text.

Paul

On Wed, 17 Jan 2018 06:28:20 -0500, Paul
wrote:

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ???
LOL. Maybe he inserted a couple of #pragma and
20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would
do that (we had such a kook at work).

Hardly. He is simply someone who makes different trade-offs in
his programming.

If you work with Assembly language a lot and have a good
Assembler, it would hardly be impossible to do.

[snip]

Sincerely,

Gene Wirchenko

Gene Wirchenko wrote:
On Wed, 17 Jan 2018 06:28:20 -0500, Paul
wrote:

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.
That page says it's "written in assembler" ???
LOL. Maybe he inserted a couple of #pragma and
20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would
do that (we had such a kook at work).

Hardly. He is simply someone who makes different trade-offs in
his programming.

If you did that and didn't tell your employer, you'd
probably be fired.

Because by not using a HLL, you're wasting company time.

You "break into assembler" for:

1) Short data-intensive routines needing absolutely
top-flight efficiency (copy look in FP register,
SSE instructions, AVX512). This also includes writing 20
copies of the same routine, so it runs fast on an
AthlonXP and on an Itanic. As you go through all the
generations of Core processors, your copy loop could
use different/better instructions or register sets.

2) The possibility of emitting the 70% of instructions
that HLL don't generate. In the case of the above application,
he could be emitting privileged CPUID instructions to
get back the CPU revision number. But you only need
a short stanza of inline assembler to do that.

In Windows now, you can make a pretty decent skeleton
for the GUI portion of the program, in less than a page
of code. At one time, in the old days, it took about
12 pages of code, before you could even printf(HelloWorld).
That was a disincentive to using the provided tools.


If you work with Assembly language a lot and have a good
Assembler, it would hardly be impossible to do.

For a system at work, approximately 120KB of assembler were
written and paged into some cheesy 8 bit processor. It took
two guys around a year to do that. Gibsons code is around
that size (even though it runs on a 32 bit processor).

There is the potential to waste a lot of time, "being efficient"
when "being efficient" is not needed.

This is why, as a hardware guy, I used to be an evangelist
for the Profiler our kernel guy wrote. It would detect
hot spots in code, and tell you whether all the time
in your program, was being wasted in three lines of code.

One day, when I promoted the Profiler to one of our software
guys (someone writing some sort of package for some GPID
thing), he came running back to me a couple hours
later and said "I found some code that got copy/pasted
into the source by accident, and was wasting 25% of my
performance". So that's what you do, besides Lint and
Code Review. Pop a good sized project into a profiler
and see whether the hot spots you detect, actually
seem reasonable. Then decide whether you need to
do something about it or not.

I was in the Assembler camp at one time too, but
that was more for the experience, than with any
kook-driven conviction. Our management, claimed
that our HLL was within 10% of the speed of
writing the equivalent function in assembler,
and at the time, that seemed a reasonable metric.
You could strip line numbers and symbols before
shipping the code, so there wasn't a lot of extra
overhead. A peephole optimizer blended the individual
HLL chunks emitted, to remove the "inefficiency".

In Windows, like Visual Studio, symbols are stored
in a separate .pdb file, and normally only the
developer needs those.

Paul