Announcement

Collapse
No announcement yet.

Richard Stallman Calls LLVM A "Terrible Setback"

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Luke
    replied
    NSA attack is believed to be on random number generator

    Originally posted by profoundWHALE View Post
    Wait, did I miss the tinfoil hat handouts?

    Also, with you guys going on about the NSA, who's to say they didn't put backdoors right into the CPUs THEMSLEVES. (I'm referring to x86) They do have built in encryption/decryption which was worked on by the NSA don't they?
    The NSA does not want EVERYONE to be able to defeat encryption, or all foreign countries get to read US government and corporate comms. If every kid with 4 Radeon 6990s on a board can brute-force encryption used by banks, guess what happens to online banking and sales?

    A secret register storing encryption keys would be forever etched in silicon, waiting to be found by the MSS, the FSB, or even some kid noticing odd behavior in an unusual binary he wrote. Thus, it is believed that the NSA may have instead compromised Intel's random number generator, so as to generate a weaker set of random numbers that could be predicted with the computational resources available to the NSA, but not otherwise. This would be in line with known NSA hacks on encryption embedded in some commercial application suites that work by making part of the key fixed and known, so as to reduce the keyspace to something the NSA believes nobody else can brute-force but which they can.

    Linux kernel developers refused the "advice" of Intel to simply map /dev/random to the hardware "random" number generator and are now damned glad they did. Instead, they chose to take the output of the legacy software random number generator and Xor it with the output of Intel's. Since predicting the output of Xor requires knowing both inputs, the result is a random number generator more secure against adversaries other than the NSA and at least as secure against the NSA. If the NSA has anything more than this, they are not about to risk blowing Intel out of the water over the location of an ALF/ELF fugitive, much less over that warrant for your refusal to show up in court for an "underage" drinking case. The existance of Intel is worth too much to them.

    When you refuse to decrypt your laptop for TSA thugs, they will probably attempt a dictionary attack at most. If they return the machine, throw it out if it has been out of your sight, as TSA or Secret Service would gladly admit in court to flashing a new BIOS in a single machine under these conditions.

    Leave a comment:


  • torsionbar28
    replied
    Originally posted by Sonadow View Post
    And Stallman's agenda now becomes clear.

    "You must give your stuff to us with no restrictions because we want them and we need them to help us, but you're not getting your hands on OUR stuff because we don't want to help others ."
    Huh? I don't think you read the same article as the rest of us. Your "interpretation" of the goals of Free software couldn't be more obtuse and wrong.

    Leave a comment:


  • profoundWHALE
    replied
    Originally posted by Cann View Post
    I don't trust LLVM simply because of the large involvement of Google and Apple, especially because of PRISM and Ken Thompson' compiler hack.
    Wait, did I miss the tinfoil hat handouts?

    Also, with you guys going on about the NSA, who's to say they didn't put backdoors right into the CPUs THEMSLEVES. (I'm referring to x86) They do have built in encryption/decryption which was worked on by the NSA don't they?

    Leave a comment:


  • erendorn
    replied
    Originally posted by Luke View Post
    Due to this, I have never owned a smartphone and do not carry a dumbphone with the battery in it either. I refuse to allow my personal information to be on a device with networked firmware controlled by known malicious cell phone companies. Even if you could reflash all the firmware, what about mask-programmed ROMs that might contain immutable malicious code? Unless you know for a fact that they are absent, you must assume they are present.

    You can use their networks, but connect to them only by wi-fi, USB, or preferably wi-fi by a USB wi-fi device to their hotspot, as a hacked/malicious network card on your PCI/PCI-e can be used as a "Bus Pirate," becoming bus master and writing to/replacing your BIOS. On the other hand, for the same carrier to get past first their own wifi hotspot, then get control of a USB wifi card, then get control of your chipset via the USB bus is a lot more difficult.

    Also don't carry any connected/operating device while travelling, or your trip is certain to be logged in a searchable database.
    1) Unusual behaviour makes you more likely to be tracked by standard methods.
    2) Have you any evidence of any such things having ever been found, by, say, any non-US intelligence agency (that would look for it, and have jurisdiction were these devices are manufactured)? Or even from US agency leaks?

    Leave a comment:


  • Cann
    replied
    I don't trust LLVM simply because of the large involvement of Google and Apple, especially because of PRISM and Ken Thompson' compiler hack.

    Leave a comment:


  • Luke
    replied
    That's why I don't have a smartphone

    Originally posted by brosis View Post
    <snip>It supports the assertion, the layer exists on ANY CELL PHONE, it has FULL ACCESS FROM CARRIER, it supports DIRECT WRITES INTO MEMORY and DIRECT EXECUTION, it is FULL OF BUGS, it is PROPRIETARY, it is written with NSA SUPPORT, it is the ONLY REASON why mobile devices are HACKED FOR TRACKING USE. <snip>
    Due to this, I have never owned a smartphone and do not carry a dumbphone with the battery in it either. I refuse to allow my personal information to be on a device with networked firmware controlled by known malicious cell phone companies. Even if you could reflash all the firmware, what about mask-programmed ROMs that might contain immutable malicious code? Unless you know for a fact that they are absent, you must assume they are present.

    You can use their networks, but connect to them only by wi-fi, USB, or preferably wi-fi by a USB wi-fi device to their hotspot, as a hacked/malicious network card on your PCI/PCI-e can be used as a "Bus Pirate," becoming bus master and writing to/replacing your BIOS. On the other hand, for the same carrier to get past first their own wifi hotspot, then get control of a USB wifi card, then get control of your chipset via the USB bus is a lot more difficult.

    Also don't carry any connected/operating device while travelling, or your trip is certain to be logged in a searchable database.

    Leave a comment:


  • artivision
    replied
    Originally posted by mrugiero View Post
    And you don't know what you talk about either, it seems. First things first, JIT compilers basically do as you say. Yay for it. However, if you want software to be optimized to the actual computer it runs on, you could as well build it locally once and be done with it, instead of building every time it runs, which increases the startup time (note, this is probably partly solved by caching the binaries generated; I don't know enough of the subject to know if actual JIT-compilers do that, but it sounds sensible enough to assume most of them do); after all, optimization is usually the most expensive part of compiling, and you only get to avoid repeating the lexing and parsing when you JIT, maybe some parts of the optimization, but the more you do before deployment is the less you can do specifically for the machine running it. On the other hand, you are TERRIBLY AWFULLY WRONG when you assume LLVM implies JIT, or that there are no GCC JIT, although the latter I acknowledge it's more an experiment than a production quality thing. Maybe we read you wrong, but in all of your posts you seem to imply that LLVM implies JIT compilation, which is not the case, really. I can't stress that enough. I can give you a statically compiled binary and you will not be able to run it in other architectures, nor to optimize it locally, because it's not JIT, while being done with LLVM (through CLANG).


    You add to the conversation the "static hack". Can be done with just 10-20% more data vs the main binary and you can hold those bytecode extensions in home folder or temp. Can be done for LLVM, Wine_GLSL (forcibly stop HLSL compilation for the same object again), Qemu. It does not exist today. The first who will do it, will be a hero. All the rest are suspicious.

    Then you say that LLVM doesn't imply JIT, because can compile like the rest and because the rest have JIT. My opinion is the opposite. LLVM developed for JIT from the beginning, the rest are all addons. The difference between LLVM and the rest of the JIT is that LLVM has new things and thinks that make it efficient and functional. As a compiler is very evolved for JIT and does have things that are not exist to other compilers. Can work as Java or OpenCL compiler to. I don't think there is an alternative to this department. And i think that when LLVM can compile the 100% of the today's code, will be used only for JIT (Android for example). The today's use its just an experiment.

    We on open source, we only use it for shaders because we have the sources. But imagine what if a big graphics engine (unreal) use it and only with JIT (like C11+LLVM_JIT) instead of Intel or MS compiler. ISA proprietary computing can be killed in favor of open source processor. This couldn't be done with previous underdevelopment JIT plugins. With LLVM its a first!!! And that's exactly where i am right.

    Leave a comment:


  • erendorn
    replied
    Originally posted by boltronics View Post
    Or to put it another way:

    BSD: Usually free, but allows developers to restrict users through proprietary forks.
    GPL: Free, and ensures the code stays that way.
    Nope. The code itslef is and stays free in both cases.
    Only contributions (as in new, additional work) can be proprietary or not.
    Users can avoid being restricted by not using proprietary additions, and contributors can avoid distributing their code by not contributing.
    So all in all it is not as obvious as you think.

    Leave a comment:


  • Thaodan
    replied
    Originally posted by pasaulais View Post
    Companies are giving back contributions to LLVM. The reason is simple: maintaining your own fork requires a lot of work that could be spent doing something useful.

    Some of these companies just take LLVM/Clang and make changes anywhere in the source tree (without contributing these changes back) because it's the easiest thing to do for them. Then months/years down the road they realise how much work it is to merge these changes with new releases. That's when they start tracking tip and pushing back changes upstream in order not to waste so much time merging and not to be months/years behind everybody else in terms of features, optimizations, etc.

    Of course what they contribute back is often a small part of their work. But that's usually the code that is most useful to the community, e.g. changes to the shared, architecture-independent code.
    Unless its no issue for them, for example if Sony uses LLVM for their PS4 infrastructure and add some code that open their ecosystem (app signing etc) they won't push it in the cvs.

    Leave a comment:


  • profoundWHALE
    replied
    Wow, you guys are still going at it. If we're going to argue about licenses we should at least make it a little more organized in another thread.

    Leave a comment:

Working...
X