If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#31
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
On 18/01/2018 in message
XnsA86DE9765B573HT1@3pt7fw8U7aCGtyJCnVIIkUzL6V7eb B2xECPht83.A334jDo4AfjRd6C Diesel wrote: I was somewhat startled in discussion with a youngish computing graduate - I think in the last ten years, but probably not much more recent than that - to discover he'd never done any assembler. But IT is so big these days that there will indeed be room for people at all levels. And, sad though it may be for some of us oldies, modern processing power (and storage, both RAM and disc) are such that it really isn't necessary to write compact code (unless you're writing for microcontrollers - and even those have huge amounts compared to what I grew up with). Those are not valid reasons to cease writing tight/compact code. Those are excuses to make your program bloated and resource wasteful and we continue to see ample evidence of just that. Absolutely! That, unfortunately, is what MSFT does. -- Jeff Gaines Wiltshire UK There is no reason anyone would want a computer in their home. (Ken Olson, president Digital Equipment, 1977) |
Ads |
#32
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
Diesel wrote:
"J. P. Gilliver (John)" Thu, 18 Jan 2018 00:22:19 GMT in alt.windows7.general, wrote: In message , pjp writes: [] I'm surprised people find assembler something they don't expect to be used anymore. I would suspect that an assembler level programmer would build up a toolbox of canned routines used over and over again no different than people constantly using any language. Even in C/C++/Pascal & Delphi (geez even dBase in it's day) I had a library of "utility" routines I constantly used. I was somewhat startled in discussion with a youngish computing graduate - I think in the last ten years, but probably not much more recent than that - to discover he'd never done any assembler. But IT is so big these days that there will indeed be room for people at all levels. And, sad though it may be for some of us oldies, modern processing power (and storage, both RAM and disc) are such that it really isn't necessary to write compact code (unless you're writing for microcontrollers - and even those have huge amounts compared to what I grew up with). Those are not valid reasons to cease writing tight/compact code. Those are excuses to make your program bloated and resource wasteful and we continue to see ample evidence of just that. Surely the point is that the source should be easily maintainable and easy to understand - it's the compiler's job to turn that into compact object code. |
#33
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
On 18-Jan-18 4:37 AM, VanguardLH wrote:
woo wrote: Paul wrote: He also mentions why AVs were false triggering on his InSpectre.exe file when users were downloading it. One of his on-off toggles involves a registry change and AVs where triggering on it. So he encrypted the registry key's name and data item value. Interesting, I'm not sure how that would work as I'd have thought he'd have to be calling RegOpenKeyExA and RegSetValueExA where obviously these are procedures in an external masm library. Or I guess what I'm saying is that I personally would have no clue how to insert an encrypted key name in the actual asm code that followed. Although his tool still writes to the registry, the AVs stopped triggering on that behavior (they didn't know what was the registry key's unencrypted name). He submitted a test version in his private forum to have his subscribers check if the AVs were still triggering on his .exe file. The download is dated today but I don't know if it is his test release he gave to his subscribers and fellow testers. Avast did not alert on the file's download or run. |
#34
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
In message , Paul
writes: J. P. Gilliver (John) wrote: From what I've seen, C (for example) produces a lot of inefficient code, which on the whole I'd say I could recognise. In the hands of the wrong individual, yes. Depends on whose definition of "wrong" you are using (-: ******* You can compile to .s format, which is assembler metainstructions, and see what the code quality looks like. The example at the top of this page, is a particularly poor choice for an efficiency explanation. What I want to point out in this link, is you can generate a .s file using GCC, then examine it in comfort. You don't have to use a hex editor on the object code, to review what it's doing. https://stackoverflow.com/questions/...le-the-asm-gen erated-by-gcc Thanks; I've saved your post for future reference, but I suspect my coding days are long past: I haven't written any code (apart from a bit of HTML, and that HTML 3) for years. I've never coded for a GUI. Try some arithmetic statements in your test.c, then tell me how efficient the test.s is, and how much wonky overhead there was. If you really need efficiency, you don't have to drop to assembler and do the whole thing there. You can simply review the .s and hand-optimize your source as desired. (I take it .s is for "source code"?) That only works if you have the #pragma to generate whizzy instructions. For example, you might have to do something special to have an instruction sequence emitted as AVX512 say. You should have no problem generating ADD,SUB,MUL,DIV with a little (integer) test program. You can also experiment with compiler optization, like -o, -o2 and so on, and see what effect that has, Maybe some assembler is moved out-of-order, for better performance. Initially, you'll want to test with no -o at all. I just wonder how much of this sort of optimisation is widely done these days: with the possible exception of high-density crunching app.s, like video and perhaps audio processing, is it worth the programming effort (which equates to money for commercial software producers, and time even for freeware ones - though I feel the latter _do_ do it more). With modern multicore processors, and OSs (?) that optimise code between cores even if the original code doesn't, and the plummeting cost of RAM and HD storage, who's going to even notice the odd extra second or so here and there. (Not to mention the willy-waving aspect _some_ software vendors, or _some_ of their departments, seem to still have about code size ["if the code needs a DVD or two to be installed from, it must be good"].) Programmer time (resource) is often seen as better spent adding new features, or - occasionally - fixing bugs, that code optimisation (with the exceptions I have mentioned, plus some scientific purposes, and maybe server software). [The same of course applies to the supporting of older OSs.] If you don't think the game is honest, there's at least one free disassembler for x86 you can get. And you can review the code after object is generated. Reverse engineering. Hard work (-:, for not-your-own code! (Not easy when it _is_ your own!) Paul John -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf .... the pleasure of the mind is an amazing thing. My life has been driven by the satisfaction of curiosity. - Jeremy Paxman (being interviewed by Anne Widdecombe), Radio Times, 2-8 July 2011. |
#35
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
Diesel writes:
"Mayayana" news Wed, 17 Jan 2018 20:13:52 GMT in alt.windows7.general, wrote: 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. Actually, most of the time, with the exception of a select few compilers; that's not the case. They compile to pseudo machine language with a runtime present inside the executable that performs the low level translation work. There are some exceptions to this, but the more well known compilers are not taking your c/c++/basic source code and translating it verbatim to machine code inside your executable. Which C/C++ compilers do you think do this rather strange thing? A moment with a disassembler will reveal that GCC, Clang and MSVC do not. -- https://www.greenend.org.uk/rjk/ |
#36
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
"Diesel" wrote
| 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. | | Actually, most of the time, with the exception of a select few | compilers; that's not the case. They compile to pseudo machine | language with a runtime present inside the executable that performs | the low level translation work. You mean like a python program? I'm talking about compiled software. Compiled to native code. What's running when just about any software you use is running. (For the most part, .Net, Java and Python are not running on desktops.) Many have "runtimes". All of the VC++ versions have runtimes. But those are companion function collection libraries, also compiled to native code, not interpreters. | 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. | | Native win32 assembly can also make full use of Win api functions; In | fact, you're encouraged to do so. Yes, but why? He's making a GUI program that uses a Richdit window, 3 system button windows, and RTF text. Why not use a tool designed to do that more easily and save the low level code for things that require low level? I can use an old fashioned hand drill to drive drywall screws, at least in theory, but it's going to take an awfully long time. I could learn to start a fire by rubbing sticks together. I could refuse to use "lazy", "high level" technologies like running water and gas stoves and electric lights. And of course, some people do that. It might be an interesting experience or an impressive discipline, but not necessarily the best way to spend one's time. |
#37
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
Bill wrote:
VanguardLH WROTE: Besides the AVs looking for the malicious behavior, the OS gets patches to mitigate the attacks. Only time will tell if Microsoft will use the patches to leverage their customerbase in pushing them to Windows 10 by not providing the updates to prior versions of Windows. As the original follow-up was limited to one ng, My client warns me if FollowUp-To is used. Polite use is limited to very few scenarios, like submitting a spam exhibit in one newsgroup but discussing it in a different newsgroup (to keep the exhibits clean). Otherwise, it is rude to shotgun a post by cross-posting to multiple newsgroups where there is no intention to involve those other communities. If you use FollowUp-To, you should only be posting to one newsgroup (but then you don't need FollowUp-To for that). It is rude to yank away the discussion to the other newsgroups if you wish not to continue the discussion over there. I'll repeat my observation that when I run this tester on my 32-bit Windows machine, I get a message that Microsoft is only providing patches for 64-bit systems and has no plans to change this. Not only for 64-bit only machines but also only for the latest release of Windows 10. So far, Microsoft has not released its patches for Windows 7 & 8. That may change. Depends on how long Microsoft wants to use this as leverage to push users off their old OSes. Remember the original cutoff date for Windows XP support but that got extended? The same could happen for Windows 7 & 8 regarding these security patches. Windows 7 still has extended supported until 13-Jan-2020 for security updates - and these fixes are definitely security updates. If Microsoft doesn't update Windows 7 & 8 then they lose all that marketing blitz regarding their claimed security support. I very much doubt Windows XP will ever receive these updates. The timing is so close between when Microsoft pushed their security updates to when Google released their open source Retroline (Return Trampoline) solution. If Microsoft did not incorporate Retroline, they may do so in a later update. Microsoft's patch incurs a performance hit in all implementations as they used only one instruction (something like CPUid) instead of also using the other paired instruction (something like invCPUid). The two together incur not performance penalty but using only one does. However, while the CPUid instruction was added to Intel processors somewhere around 2003, the 2nd instruction wasn't added until the Haswell family and thereafter. I'm still using an old Intel Core 2 quad-core processor so the security updates, if and when available, WILL incur a performance penalty on my machine. There are ton of Core 2 hosts still out there (last I checked, Core 2 outnumbered all the other active processor usage). Haswell was for 4th generation, and later, of the [Core] i3, i5, and i7 processors. Folks with smartphones are in an even worse situation. Typically locked (branded) phones don't get OS updates. The cellular providers don't want the image or state of their products changing because that means more support. I've had several locked phones that NEVER got updates. Even unlocked phones may not get updates. LG decided to skip 7.1 and go directly from 7.0 to 8 for an OS upgrade but who knows when that will get pushed to customers, especially now that they'll have to wait a bit longer for yet another Android version that incorporates the security updates. Pixel users will get updated but others will have to wait or never get the updates so smartphone will remain vulnerable for a very long time. All IoT devices will remain vulnerable for a long time. I'll wait until the vulnerabilities actually show up in the wild. I'm not panicking over POCs. |
#38
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
On 18/01/2018 08:44, Bill wrote:
As the original follow-up was limited to one ng, I'll repeat my observation that when I run this tester on my 32-bit Windows machine, I get a message that Microsoft is only providing patches for 64-bit systems and has no plans to change this. I have to maintain a couple of 32-bit machines here because of certain hardware and software constraints. This is an old PC, and although it's 64-bit capable I put Windows 7 32-bit on it all those years ago. If MS really are going to withdraw support I'll be force to put Ubuntu on it (which I use at work). That won't help MS... Andy |
#39
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
Mayayana wrote:
"Diesel" wrote | 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. | | Actually, most of the time, with the exception of a select few | compilers; that's not the case. They compile to pseudo machine | language with a runtime present inside the executable that performs | the low level translation work. You mean like a python program? I'm talking about compiled software. Compiled to native code. What's running when just about any software you use is running. (For the most part, .Net, Java and Python are not running on desktops.) Many have "runtimes". All of the VC++ versions have runtimes. But those are companion function collection libraries, also compiled to native code, not interpreters. | 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. | | Native win32 assembly can also make full use of Win api functions; In | fact, you're encouraged to do so. Yes, but why? He's making a GUI program that uses a Richdit window, 3 system button windows, and RTF text. Why not use a tool designed to do that more easily and save the low level code for things that require low level? I can use an old fashioned hand drill to drive drywall screws, at least in theory, but it's going to take an awfully long time. I could learn to start a fire by rubbing sticks together. I could refuse to use "lazy", "high level" technologies like running water and gas stoves and electric lights. And of course, some people do that. It might be an interesting experience or an impressive discipline, but not necessarily the best way to spend one's time. Personally, I prefer that people keep their implementation details to themselves. If you wrote it in LISP or COBOL, that's your business. I can relate a work story. We had labs in multiple cities at work. One of the other labs, a guy shows up one day, to show us the LAN he's built up for our computers. Now, if you want to give a demo, you'd bring some hardware cards, a couple pieces of cable, and give a demo. Then the audience could go "ooh shiny" and so on. Coffee and muffins afterwards. What does he do ? As an evangelist, he shows up with zero hardware samples, nothing to look at in the hardware area. *But*, the idiot does bring a 3" thick stack of *assembler listings* and says "see, I wrote all the code for this project in assembler". In other words, "I'm a kook, and I'm here to make your day". And he keeps waving that stack around. Rather than promoting his project, he was actually an assembler promoter. I can tell you the reception he got was pretty chilly. If the guy had said to himself "what hot button can I push to **** people off in a work context", he succeeded :-) It would be like he showed up for the presentation, not wearing any pants. Now, that's the situation I would want to avoid. You can be proud of many things (your new LAN invention), but writing a 3" stack of assembler for the *whole* thing, isn't one of them. It would be like the dry waller showing up at your house, to do a quote, and keep waving boxes of dry wall screws around in front of your face :-) Or maybe showing you the *hammer* he plans on using, to drive the screws into the dry wall :-) Most people just want to see that smooth flat wall when the job is done. If we weren't forced to contemplate these things as an audience, we'd be much happier. The details of making sausage might not be all that palatable. The author of Prime95 writes in a mix of HLL and assembler. He has hand-optimized custom FFT routines, as that's how he screens for Mersenne primes. And different code modules are provided for the more modern processors (he's somehow used one of the flavors of AVX for this). You could make an argument that the split makes sense. The "hot spot" in the code, is in assembler. The GUI is not. Paul |
#40
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
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 |
#41
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
On 17/01/2018 15:10, Wolf K wrote:
On 2018-01-17 08:24, 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 OK, but is he a clever loon? Definitely. He uses a large library of macros with assembler so his code does look rather like a weird high level language of his own design. -- Brian Gregory (in England). |
#42
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
On 17/01/2018 11:28, 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). This is very "I couldn't do it therefore anyone who could is weird". I know most people like to write in high level languages and adopt a get something down now and we can poke and prod at it randomly later until it seems to work right. Surely being able to write code in a language that more or less demands you get it 100% right first time and succeed in getting it right is something to be admired. -- Brian Gregory (in England). |
#43
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
On 17/01/2018 09:26, PeterC wrote:
https://www.grc.com/inspectre.htm with a warning not to d/l from other sites. All the details he https://www.youtube.com/watch?v=Lh6E...u.be&t=1h8m26s -- Brian Gregory (in England). |
#44
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
Brian Gregory wrote:
On 17/01/2018 11:28, 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). This is very "I couldn't do it therefore anyone who could is weird". I know most people like to write in high level languages and adopt a get something down now and we can poke and prod at it randomly later until it seems to work right. Surely being able to write code in a language that more or less demands you get it 100% right first time and succeed in getting it right is something to be admired. It's called using the right tool for the job. I can build the Taj Mahal from toothpicks, but that doesn't make it right. For some tasks, you have to drop to assembler, as a HLL just won't do. If you're good, you'll use your tools selectively, a hammer for hammering, a screwdriver for driving screws - not a hammer for driving screws. A GUI doesn't need to be built from assembler. That's why they put all those APIs and libraries there, so you need less than a page of code to put it on the screen. If you need to emit a privileged CPUID instruction in your code, I'd buy the need to do a little inline code or the like, to do it. Some things require a few tricks, if they aren't in a library already. Paul |
#45
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
On 19/01/2018 00:48, Paul wrote:
Brian Gregory wrote: On 17/01/2018 11:28, 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). This is very "I couldn't do it therefore anyone who could is weird". I know most people like to write in high level languages and adopt a get something down now and we can poke and prod at it randomly later until it seems to work right. Surely being able to write code in a language that more or less demands you get it 100% right first time and succeed in getting it right is something to be admired. It's called using the right tool for the job. I can build the Taj Mahal from toothpicks, but that doesn't make it right. For some tasks, you have to drop to assembler, as a HLL just won't do. If you're good, you'll use your tools selectively, a hammer for hammering, a screwdriver for driving screws - not a hammer for driving screws. A GUI doesn't need to be built from assembler. That's why they put all those APIs and libraries there, so you need less than a page of code to put it on the screen. If you need to emit a privileged CPUID instruction in your code, I'd buy the need to do a little inline code or the like, to do it. Some things require a few tricks, if they aren't in a library already. Â*Â* Paul Just because it's not the right tool for you doesn't mean it's not the right tool for someone who does it all the time and has a massive library of macros to help him. I bet most of the 5 or 6 days it took him to do it were taken up with reading and understanding the processors and the vulnerabilities anyway. -- Brian Gregory (in England). |
Thread Tools | |
Display Modes | Rate This Thread |
|
|