|
I think the most useful thing you can do is find (or write) a bunch of lovely code and debug it, until you get a good intuition of all of the hosed up edge cases that can compound themselves. Get real handy with GDB or windbg. The second most useful thing would be to read technical documentation front to back. Books on the topic are good for offering some perspectives on how to approach a problem, but it's something you've really gotta know from the bottom up, because that is your advantage as an offender. Instead of starting off with something that is explicitly related to security, pick up a comp org book like "Computer Organization and Design" or "Write Great Code Vol. 1", and then read the processor development manuals: http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html http://developer.amd.com/resources/developer-guides-manuals/ If you don't understand how something works, just write a little C program to prod the thing and see how it jiggles, and then extend what you've discovered to a functional program. When it comes a remote host running an arbitrary service, the best you can do is gather up as much information as possible about the system and try to mock it up locally. Also keep in mind what seems absurd from a "normal" development standpoint is common place in malicious code. You really could give a poo poo less how long something takes or how much memory you're using, as long as the end goal is accomplished. The machine will perform its duties, either way. I was a real ornery teenager before ASLR came into use ... JawnV6 posted:Fun to think about new features reducing ASLR's efficacy: Dedup Est Machina: Memory Deduplication as an Advanced Exploitation Vector. Craft pages that look like one with a guess as the randomized portion, write and see if it had been deduped. Wow they really took that all the way, this is good stuff. dougdrums fucked around with this message at 12:19 on Aug 18, 2016 |
#
?
Aug 18, 2016 12:04
|
|
|
|
| # ? May 15, 2024 15:17 |
|
|
Jsor posted:I still don't understand how buffer overflows that allow the user to execute arbitrary code work. I mean, the concept is straightforward, but I have no idea how I'd be able to consistently target the instruction memory I'd want to overwrite. If you actually have a copy of the program sitting around, sure, you can run a debugger on it, and since programs generally execute pretty consistently you can target the overrun. On a remote program handling multiple connections allocating memory in unpredictable addresses? No clue how people manage it. If I had to guess you just inject the first <N> bytes with your malicious code and then just put in an absurd (i.e. megabyte sized or more) number of repeating "unconditionally jump to <start of malicious block>" statements afterwards. (Though if that's the case I'm not sure how you'd get the address of the start of the block it needs to jump to).    Those are worth starting out reading. I made it through about half of each of them.
|
|
#
?
Aug 18, 2016 13:35
|
|
|
I've got a hardware-ish question: I've been looking at the precision of floating point arithmetic. I know the standard stuff like floats and doubles, and I know you can do double double emulation in software (with a big performance hit), but I've also read a small amount about 'extended precision', or 10 byte floating points. Unfortunately there's not much information I can find about it, other than it exists. My 2 questions are: Are there special parts of the CPU that do arithmetic with 10 byte floating points? Is it separate from double precision? Is there any reason I wouldn't want to use it? It appears to me that it works roughly as fast as double precision. Thanks!
|
|
#
?
Aug 18, 2016 18:58
|
|
|
Eeyo posted:Is there any reason I wouldn't want to use it? It appears to me that it works roughly as fast as double precision. Well, more memory per number
|
|
#
?
Aug 18, 2016 20:01
|
|
|
You can use SSE\AVX features on intel to at least do a few doubles at once: https://software.intel.com/sites/landingpage/IntrinsicsGuide/ or use NEON on ARM. I forgot, the x87 can use 80 bit floats but I don't know anything about it. dougdrums fucked around with this message at 20:26 on Aug 18, 2016 |
|
#
?
Aug 18, 2016 20:23
|
|
|
Eeyo posted:Are there special parts of the CPU that do arithmetic with 10 byte floating points? Depends on the architecture. I'd guess that x86 has specialized FPU parts for 80 bit numbers - I'm basing that guess on the fact that nearly every resource that mentions extended precision does it in the same breath as "x86". I do not know for sure. As an example of a CPU that doesn't have specialized hardware for it, PowerPC only supports 32 bit single and 64 bit double precision natively. If a language or library needs to implement 80 bit extended precision on that architecture then it's done in software, and therefore: quote:Is there any reason I wouldn't want to use it? It appears to me that it works roughly as fast as double precision. Same as emulated double-double precision, it would only work as fast as double precision on hardware platforms that explicitly support it in the first place. Language support and portability would be potential problems...basically, unless you're using something that explicitly exposes a "Float80," you may not actually get an 80 bit underlying data type. Take C for instance: C doesn't guarantee the availability of an 80 bit data type. long double gets you an 80 bit data type on x86 but that's an implementation detail of that platform. Are you doing anything in particular that requires extended precision? I've personally only encountered it once, working with AIFF files, and god only knows why AIFF uses it in the first place - it's in the common chunk representing sample rate in samples per second. Maybe there was a common sampling rate of fractional samples per second that singles and doubles couldn't represent? Stinky_Pete posted:Well, more memory per number But less memory per number than quad precision! 
|
|
#
?
Aug 18, 2016 20:25
|
|
|
csammis posted:Depends on the architecture. I'd guess that x86 has specialized FPU parts for 80 bit numbers - I'm basing that guess on the fact that nearly every resource that mentions extended precision does it in the same breath as "x86". I do not know for sure. The 80-bit format is mostly just an x86 quirk, yes. The x87 coprocessor uses an 80-bit denormalized internal format in order to minimize intermediate rounding errors; the format has a 64-bit significand including the explicit 1, so it's as wider as it can be without incurring a major performance penalty. When you load or store a 32-bit or 64-bit float, it implicitly converts to and from that format; it can also load and store its "internal" format directly, of course, and doing so touches exactly 10 bytes of memory. Motorola processors supported a very similar format for a few years, although it didn't have the same layout in memory. Anyway, that was the only hard float option on x86 for a long time, but most compilers these days will prefer to use SSE if it's available. But most i386 calling conventions still specify that floats and doubles are returned using the x87 registers, so it's a mess. csammis posted:Language support and portability would be potential problems...basically, unless you're using something that explicitly exposes a "Float80," you may not actually get an 80 bit underlying data type. Take C for instance: C doesn't guarantee the availability of an 80 bit data type. long double gets you an 80 bit data type on x86 but that's an implementation detail of that platform. long double isn't guaranteed to be the 80-bit format even on x86. MSVC maps it to the same format as double. csammis posted:But less memory per number than quad precision! Maybe! Linux/BSD i386 gives x87 long doubles 4-byte alignment, so an array of them will be packed better than an array of quads but still not quite perfectly. But Unix-y x86-64 targets give them 16-byte alignment, as does Darwin even on i386, so they're not packed more efficiently at all.
|
|
#
?
Aug 18, 2016 21:17
|
|
|
Wait, so are the x87 instructions and such deprecated in favor of SSE? What about programs that configure the x87 directly? Does the SSE implementation also respect those x87 registers?
|
|
#
?
Aug 18, 2016 22:42
|
|
|
Like basically. amd64 calling conventions pass floats in the xmm registers.
|
|
#
?
Aug 18, 2016 23:29
|
|
|
Thanks for the info! In my case I'm doing numerical simulations (think like tracking planets or something) where I'm concerned about the long-term behavior. In my case, I'd like to make the roundoff error as little as possible. Roundoff errors would add up over time as I track a particle, so keeping them down is good for me. I think this is my confusion though: Is there a little square inside the die that only does this 80-bit math? It just seems like that's a waste and if it's a niche thing that's being phased out and the most popular language doesn't even make it easy to use, why put it in? Couldn't they save money somehow?
|
|
#
?
Aug 19, 2016 00:06
|
|
|
Yes, but MMX regs are aliased with the x87 regs. I think FXSAVE and FXSTORE operate on both the MMX/x87 state and XMM regs.
|
|
#
?
Aug 19, 2016 00:11
|
|
|
I started learning programming in my spare time a month ago so sorry if this is too inane a question but i couldn't see a newbie thread. I have a class that stores the scores of a game between two participants. The score of each player is not necessarily available when the class is instanced so i need to store a placeholder in this circumstance. I can't use 0 because i need to differentiate between a score of 0 and the value not yet being set. Is it better to use something like –2147483648 and hope no one ever needs to store that value, or null and have (score != null) statements all over to avoid NullPointerExceptions?
|
|
#
?
Aug 19, 2016 00:16
|
|
|
CJ posted:I started learning programming in my spare time a month ago so sorry if this is too inane a question but i couldn't see a newbie thread. You need some way to signal that the value is not set. You can set it to null if you like, but an otherwise-impossible value would be preferable (I'd use -1 instead of -bignum, assuming negative scores are otherwise impossible). A third possibility is to use a separate boolean to indicate whether or not the score has been set. This has the advantage of being more explicit about what is going on (instead of using a "magical value" that has special meaning), and it's the approach I'd recommend using.
|
|
#
?
Aug 19, 2016 00:28
|
|
|
CJ posted:I started learning programming in my spare time a month ago so sorry if this is too inane a question but i couldn't see a newbie thread. If your language supports optional types, this is a perfect time to use them. Here's an article that describes their use in Java 8.
|
|
#
?
Aug 19, 2016 00:35
|
|
|
Yeah, i usually use something like 0 or -1 but in this came i'm not sure what the value would be. I'm trying to make a tournament bracket generator programme because i thought it would bring up these sorts of issues that i'd have to deal with that i didn't run into when doing prescribed tutorial problems. I can't just use -1 because there's plenty of games it could conceivably be used for that can have negative scores. –2147483648 is considerably less likely but there's still the possibility, and if i have some check to see whether both scores have been entered to determine whether to proceed to the next round the one guy playing a game where you can score –2147483648 would be stuck. I guess i should limit the valid inputs to 9 digits or so to prevent over/underflow so i guess that wouldn't be an issue. I just wanted to know which was considered better practice.
|
|
#
?
Aug 19, 2016 00:56
|
|
Eeyo posted:Thanks for the info! In my case I'm doing numerical simulations (think like tracking planets or something) where I'm concerned about the long-term behavior. In my case, I'd like to make the roundoff error as little as possible. Roundoff errors would add up over time as I track a particle, so keeping them down is good for me. I am a fan of extended precision, but am of the opinion that it should be tried only after algorithmic methods to preserve numerical stability have been found wanting. Extended precision can lead to a false sense of security w/r/t numeric accuracy. Make sure you're using the right units and time steps and as numerically stable of an algorithm as you can, first. If you're still having stability problems, then by all means use extended precision. ... man, my numerical analysis professor was awesome.
|
|
|
#
?
Aug 19, 2016 01:25
|
|
|
Eeyo posted:I think this is my confusion though: Is there a little square inside the die that only does this 80-bit math? It just seems like that's a waste and if it's a niche thing that's being phased out and the most popular language doesn't even make it easy to use, why put it in? Couldn't they save money somehow? I don't know what you mean by "the most popular language". Today, most of the code running on any particular computer is written in a C-based language (a lot of C and C++ on Windows, a lot of C, C++, and ObjC on Darwin, and almost exclusively C on other Unixes); that may not be the code that you personally are writing, but it's most of the code that's actually running. On non-Windows x86-based targets, you can directly ask for things that can only be efficiently compiled using x87. MSVC doesn't make it quite that easy anymore, but Windows cares a lot about running old binaries, and older compilers tended to use x87 for most FP computation because they were less willing to assume SSE as a baseline. (The default in VS 2015 is to assume SSE2, but you can use the /arch flag to demand that the compiler only use x87 instructions. That's on 32-bit; a86-64 added SSE2 to the core ISA, so that there are no general purpose x86-64 cores that can't do SSE2.) So if a processor dropped the x87 unit (which would make it non-compliant with the x86 spec, but let's ignore that), it would no longer to be able to run, like, Diablo II and 15-year-old versions of Excel, and customers would revolt. Companies commissioning special runs of x86 chips for non-general-purpose computing — e.g. they're buying a massive number of CPUs to put in their data centers — frequently do have specific units removed from the design, and they just compile their code in a mode that doesn't use those instructions. Suspicious Dish posted:Wait, so are the x87 instructions and such deprecated in favor of SSE? What about programs that configure the x87 directly? Does the SSE implementation also respect those x87 registers? Covered above a bit, but yes, for a couple reasons. The first is that the SSE unit can usually execute the instruction at the right native width and so avoids expensive per-operation rounding. A source language with strict FP semantics has to force rounding after every operation, and IIUC in x87 the only way to do that is actually to store it to memory and then load it back. Some languages allow FP operations to be executed with extra precision, but usually there are specific limits to that which actually hamper the implementation quite a bit. For example, in C, if I have f += g * 5;, the compiler could do the multiply and add with extra precision, but that extra precision cannot propagate through the store to f; thus even if the compiler could easily allocate f to a register, it's still stuck doing a bunch of memory operations just to preserve language semantics. But even more important is that x87 uses an operand stack, whereas SSE registers are independently named. That makes it much easier to get meaningful instruction-level parallelism from SSE, both on a processor level (since the stack abstraction actually creates a lot of complexity for the issuer) and a compiler level (since you can simply keep N different values live at once without worrying about where they are on the stack).
|
|
#
?
Aug 19, 2016 03:52
|
|
|
I want to write a desktop application that only needs to run on windows. It should be able to interface with Excel to fill placeholders in a Spreadsheet (xlsx) with information that is gathered through the application. Assuming all knowledge is equal (since I want to learn something new), what framework/language would be the fastest to prototype and develop a desktop application with. Currently I'm mostly used to do backend stuff with C#, which I assume might be the answer anyway. Edit: Some quick googling suggest that JavaFX with Netbeans as IDE and Apache POI for Excel-functionality might be the fastest. cybertier fucked around with this message at 14:25 on Aug 19, 2016 |
|
#
?
Aug 19, 2016 13:56
|
|
|
What? If you're talking to Office, use .NET. If you need something that will only ever run as a Windows desktop app, use .NET. Use .NET.
|
|
#
?
Aug 19, 2016 14:33
|
|
|
Here is an MSDN tutorial on Office interop using Visual Studio and C#
|
|
#
?
Aug 19, 2016 14:35
|
|
|
rjmccall posted:Companies commissioning special runs of x86 chips for non-general-purpose computing — e.g. they're buying a massive number of CPUs to put in their data centers — frequently do have specific units removed from the design, and they just compile their code in a mode that doesn't use those instructions. I didnt even know this was a thing. Of course, it makes sense if you think about it, but I just never thought about it before. Who is doing this and what kind of things are they customizing?
|
|
#
?
Aug 19, 2016 14:37
|
|
|
raminasi posted:What? If you're talking to Office, use .NET. If you need something that will only ever run as a Windows desktop app, use .NET. Use .NET. Is that even true when I care a lot about the speed of development? I haven't heard good things about WPF.
|
|
#
?
Aug 19, 2016 14:55
|
|
|
cybertier posted:Is that even true when I care a lot about the speed of development? I haven't heard good things about WPF. WPF takes time to learn properly, but it's amazing when you know it.
|
|
#
?
Aug 19, 2016 15:14
|
|
|
cybertier posted:Is that even true when I care a lot about the speed of development? I haven't heard good things about WPF. How fancy is your app? Boring, ugly LOB stuff is a breeze to set up - the difficulties arise when you try to get complicated.
|
|
#
?
Aug 19, 2016 15:16
|
|
|
cybertier posted:It should be able to interface with Excel to fill placeholders in a Spreadsheet (xlsx) with information that is gathered through the application.
|
|
#
?
Aug 19, 2016 15:20
|
|
|
raminasi posted:How fancy is your app? Boring, ugly LOB stuff is a breeze to set up - the difficulties arise when you try to get complicated. 3 or 4 screens with text inputs and some dynamically created inputs (i.e. show a checkbox for each whatever-element in this XML). I guess I'll give it a shot. Having experience with .net should mean it's probably my fastest approach anyway.
|
|
#
?
Aug 19, 2016 15:23
|
|
|
mystes posted:Seriously don't actually interface with excel unless you have to. It will only cause you pain. Look at the ClosedXML library to generate excel files. I hope that I can skip interop and real Excel interaction and instead use a library to just manipulate the file. Thank god it's xlsx and not xls.
|
|
#
?
Aug 19, 2016 15:24
|
|
|
cybertier posted:3 or 4 screens with text inputs and some dynamically created inputs (i.e. show a checkbox for each whatever-element in this XML). This is basically The Thing WPF MVVM Is Good At, so I think WPF is definitely the way to go.
|
|
#
?
Aug 19, 2016 15:25
|
|
|
Thermopyle posted:I didnt even know this was a thing. http://www.pcworld.com/article/2365240/intel-expands-custom-chip-work-for-big-cloud-providers.html I can't talk about any specifics; a lot of this stuff is confidential. (To be clear, I don't actually know any specifics about what Apple does here; I'm curiously better-informed about completely different companies.)
|
|
#
?
Aug 19, 2016 16:06
|
|
|
rjmccall posted:http://www.pcworld.com/article/2365240/intel-expands-custom-chip-work-for-big-cloud-providers.html
|
|
#
?
Aug 19, 2016 16:19
|
|
|
cybertier posted:I hope that I can skip interop and real Excel interaction and instead use a library to just manipulate the file. Thank god it's xlsx and not xls. Last time I had to do something like this it was pretty easy to use the Excel file as an ADO database https://support.microsoft.com/en-us/kb/278973 It's not terribly difficult and doesn't require the machine to ahve Office installed, IIRC.
|
|
#
?
Aug 19, 2016 16:53
|
|
|
mystes posted:How can this possibly be worth the cost? I don't think you are aware of the size of some of the cloud providers. Amazon spends billions each and every year on AWS hardware. Amazon runs over 40 data centers, the average having 70,000 servers. When your potential for chip sale enters the millions it's worth the cost.
|
|
#
?
Aug 19, 2016 17:07
|
|
|
mystes posted:How can this possibly be worth the cost? 1. Adding and removing components to an existing design is not anywhere near as expensive as making a new design. 2. Cloud data centers buy cores by the 100K. 3. The primary expense of running a data center is not the up-front price of the machines, it's the ongoing costs of running them, especially in power. A few percent in power savings is a big deal.
|
|
#
?
Aug 19, 2016 17:09
|
|
|
I am working on creating a ticketing system using Google forms and sheets for tracking. I'm using the timestamp from the form submit as a case number, it's arrayed into a column and formatted to show as a number value on the sheet that captures the responses. The sheet has a script that pushes an email with the form responses to the team. Everything works great except I can not figure out how to display the timestamp in the case number format in the email, similar to how it appears on the sheet. Any ideas?
|
|
#
?
Aug 19, 2016 18:17
|
|
|
rjmccall posted:1. Adding and removing components to an existing design is not anywhere near as expensive as making a new design. Supposedly Google would absolutely switch to a Power architecture for its systems, even for a single generation, if it could get a 20 percent price/performance advantage. http://www.nextplatform.com/2015/04/29/google-will-do-anything-to-beat-moores-law/
|
|
#
?
Aug 19, 2016 18:20
|
|
|
Intel also bought Altera since the (e: 2014 upthread) posted article, so it's just integrating another in-house IP. Bet it sounds cheap compared to "ARM eats your server lunch, too" edit: quote:Google has apparently been noodling Power-based systems for a while, because Hölzle said that the company was struggling to port its homegrown Linux and application stack to Power chips until IBM switched to little endian byte ordering with the Power8 chips. “Before, we were struggling, but with Power8, within days, everything worked.” JawnV6 fucked around with this message at 18:34 on Aug 19, 2016 |
|
#
?
Aug 19, 2016 18:28
|
|
|
Bob Morales posted:Supposedly Google would absolutely switch to a Power architecture for its systems, even for a single generation, if it could get a 20 percent price/performance advantage. Except that development and debugging on POWER sucks, because nobody spent time making a good toolchain. ARM is the best non-x86 toolchain we have, but even right now it's super painful and most people I know develop apps on x86 and then spend a few weeks "porting" to ARM. When gdb flat out lies to you, POWER won't be an option. Otherwise, POWER is a great ISA for compiler writers, but it's impossible to read. Nobody learned from Itanic, I guess.
|
|
#
?
Aug 19, 2016 18:40
|
|
|
For what it's worth, while there are a lot of ways that different processor models get customized, nobody is ever going to remove the old-school 80-bit FPU compatibility from modern large x86 processors. There are a few reasons: First, it's really small. You just don't save much space by removing it from the layout. Secondly, and related, it's not typically adjacent to any interesting scalable structures on the layout like caches, so even if you take it out it's really hard to use that space for something useful. You'd have to redesign the whole layout to make use of that space, and that would probably compromise performance of something else and require a whole new set of masks, so it'd be monumentally expensive. Third, it doesn't take any power unless you're using it. When you aren't generating FP operations, it's gated completely off. Fourth, you can't "just remove it" - you'd either have to add in microcode to emulate it, or you'd have to add a whole new set of fault flows to handle no-longer-supported instructions. Either way, that's a lot of validation effort that would be very easy to have problems in, all for a really marginal theoretical benefit for a very small number of customers. The only place you might see this kind of decision is in the extreme-space-constrained embedded market, where you're contemplating things like "building an in-order core" and "not having any hardware floating point whatsoever". And while that market does exist, it's incredibly special-purposed and not really comparable to the kinds of model customization that the likes of Amazon and Google will demand on the modern large cores.
|
|
#
?
Aug 19, 2016 18:47
|
|
|
also honorable mention to https://twitter.com/ppcinstructions
|
|
#
?
Aug 19, 2016 19:11
|
|
|
|
| # ? May 15, 2024 15:17 |
|
|
Suspicious Dish posted:Except that development and debugging on POWER sucks, because nobody spent time making a good toolchain. ARM is the best non-x86 toolchain we have, but even right now it's super painful and most people I know develop apps on x86 and then spend a few weeks "porting" to ARM. Google does, in fact, employ people who work on toolchains.
|
|
#
?
Aug 19, 2016 19:15
|
|