Until the GPU is accessible by the browser and any website can execute code on it. Or the attack can come from a different piece of software on your machine.
Rowhammer allows you to corrupt/alter memory physically adjacent to memory you have access to. It doesn't let you read the memory you're attacking.
There's PoC's of corrupting memory _that the kernel uses to decide what that process can access_ but the process can't read that memory. It only knows that the kernel says yes where it used to say no. (Assuming it doesn't crash the whole machine first)
Suppose you have access to certain memory. If you repeatedly read from that memory, can't you still corrupt/alter the physically adjacent memory you don't have access to? Does it really need to be a write operation you repeatedly perform?
> Does it really need to be a write operation you repeatedly perform?
Yes. The core of rowhammer attacks is in changing the values in RAM repeatedly, creating a magnetic field, which induces a change in the state of nearby cells of memory. Reading memory doesn't do that as far as I know.
A simple hello world in C++ can pull in dozens of megabytes of header files.
Years back I worked at a C++ shop with a big codebase (hundreds of millions of LOC when you included vendored dependencies). Compile times there were sometimes dominated by parsing speed! Now, I don't remember the exact breakdown of lexing vs parsing, but I did look at it under a profiler.
It's very easy in C++ projects to structure your code such that you inadvertently cause hundreds of megabytes of sources to be parsed by each single #include. In such a case, lexing and parsing costs can dominate build times. Precompiled headers help, but not enough...
> Now, I don't remember the exact breakdown of lexing vs parsing, but I did look at it under a profiler.
Lexing, parsing and even type checking are interleaved in most C++ compilers due to the ambiguous nature of many construct in the language.
It is very hard to profile only one of these in isolation. And even with compiler built-in instrumentation, the results are not very representative of the work done behind.
C++ compilers are amazing machines. They are blazing fast at parsing a language which is a nightmare of ambiguities. And they are like that mainly because how stupidly verbose and inefficient the C++ include system is.
> Lexing, parsing and even type checking are interleaved in most C++ compilers due to the ambiguous nature of many construct in the language.
>
> It is very hard to profile only one of these in isolation. And even with compiler built-in instrumentation, the results are not very representative of the work done behind.
Indeed, precise cost attribution is difficult or impossible due to how the nature of the language imposes structure on industrial computers. But that aside, you still end up easily with hundreds of megabytes of source to deal with in each translation unit. I have so many scars from dealing with that...
The computational complexity for lexing C++ is linear, but for parsing C++ it's super-linear, as will be many analyses. In practice, the lexing is in the noise for almost all compliers.
Good luck to naively differentiate if '>' is effectively a chevron operator or a shift operator '>>' in a random nested template expression like : 'set<vector<int>>'.
> Well, the current generation of LLMs blow away that Turing Test
Maybe a weak version of Turing's test?
Passing the stronger one (from Turing's paper "Computing Machinery and Intelligence") involves an "average interrogator" being unable to distinguish between human and computer after 5 minutes of questioning more than 70% of the time. I've not seen this result published with today's LLMs.
I only skimmed it, but I don't see anything clearly wrong about it. According to their results, GPT-4.5 with what they term a "persona" prompt does in fact pass a standard that seems to me at least a little harder than what you said - actively picks the AI as the human, which seems stricter to me than being "unable to distinguish".
It is a little surprising to me that only that one LLM actually "passed" their test, versus several others performing somewhat worse. Though it's also not clear exactly how long ago the actual tests were done - this stuff moves super fast.
I'll admit that I was not familiar with the strong version of it. But I am still surprised that nobody has done that. Has nobody even seriously attempted to see how LLMS do at that? Now I might just have to check for myself.
I would have presumed it would be a cake walk. Depending of course on exactly how we define "average interrogator". I would think if we gave a LLM enough pre-prepping to pretend it was a human, and the interrogator was not particularly familiar with ways of "jailbreaking" LLMs, they could pass the test.
A lot of AI-based PDF processing renders the PDF as images and then works directly with that, rather than extracting text from the PDF programmatically. In such systems, text that was hidden for human view would also be hidden for the machine.
Though surely some AI systems do not use PDF image rendering first!
Just thought the same and removed my edit as you comment it!
I wonder if the longer pipeline (rasterization + OCR) significantly increase the cost (processing, maintenance…). If so, some company may even remove the process knowingly (and I won’t blame them).
"String interning" is discussed in the Java Language Spec, going back to the 1990s, and wasn't novel there. It goes back at least to Lisp implementations from the 1970s. Probably even earlier than that.
I have some regrets about my choice of undergrad school, but it isn't because I went someplace cheap. I could have gone to one of the multiple state schools that would have given me half off just for being born somewhere.
Instead, I went to a school that was in my home town. I learned things when I went to college, but that school was objectively the wrong choice. Not only did it cost double what the state school would have cost[0], I missed out on the reason young people ought to go to college in the first place: a once in a lifetime chance to spend 4 years hanging out and making friends with high achieving people who would go on to shape the face of the world.
Granted, one of my college friends ended up as a senior researcher studying cancer, and another went on to work for Mozilla, but I'm pretty sure in my class of ~300, there weren't too many CTOs, VPEs, star researchers, etc. Simply going to a bigger school would have been a better choice; going to a school that was both bigger and better than my undergrad institution would have been the best choice.
I guess that's what you get when society expects a 17-year-old to make what may be the single most impactful life choice they'll ever have. ¯\\\_(ツ)_/¯
That said, going to a small liberal arts college had its advantages. I learned a lot. Some of that stuff I learned, I've even gotten to use once or twice. But, looking back, if I could send my past self a message back in time, I'd tell me to go somewhere else. I may not have been much better off financially if I had met someone in college at 20 who talked me into partnering up on some insane business venture or something, but that experience would have been priceless.
--
[0]: This was even after I got a scholarship that reduced my estimated family contribution to 2/3 of what the sticker price was, on top of being able to stay at home and save money that way.
At a previous job, with a huge C++ codebase and ~100 developers over 20 years, many platforms supported, a build could take hours, and the test suite took so long to run that it would take several days or weeks of real time to get through it all.
This cycle time combined with occasional unexpected interactions between components meant that in every release cycle, there were dozens of complicated failing tests where it was not obvious which code change was responsible.
`bisect` here was extremely helpful: instead of having to pore over commit history and think very hard, I could bisect with a small wrapper script that would build and run the failing test in question. Builds still took hours, but I could usually autonatically pinpoint the responsible code change for one of the tests overnight.
(This was not using Git, but Perforce, for which I had to write `p4-bisect`. Alas, it's not open-source...)
> in every release cycle, there were dozens of complicated failing tests
Sorry if this is a dumb question, perhaps I'm not understanding what you mean by every release cycle, but does this mean nobody in the team/company ran tests until it was time for release? That sounds like a really big everlasting wound to put a tiny git-bisect bandage on!
About a dozen OSes / configurations were supported, and the entire test suite would take a few days to run on each such configuration.
This was native desktop+server software, not a hosted SaaS thing.
Major releases were put out every few months.
Developers did run tests regularly with every change they would make, but it was infeasible to run all the tests in every configuration for each change. So they would try to choose tests to run that seemed most relevant to the code they had changed.
The entire test suite would run more or less constantly on shared machines, and every few days some new tricky failure would be detected. The tricky failures were almost always the result of some unanticipated interaction of features, frequently on the more obscure configurations (like IBM z/OS).
The problem was not that developers were not testing, but that the tests were infeasible to run every time. So instead, testing became an optimization problem.
> does this mean nobody in the team/company ran tests until it was time for release?
The OP wrote “many platforms supported, a build could take hours, and the test suite took so long to run that it would take several days or weeks of real time to get through it all”
⇒ I think they did run tests, but typically not all of them on all platforms.
