I don't know if it was filename exactly, but a similar story:

> Jon Ross, who wrote the original version of SimCity for Windows 3.x, told me that he accidentally left a bug in SimCity where he read memory that he had just freed. Yep. It worked fine on Windows 3.x, because the memory never went anywhere. Here’s the amazing part: On beta versions of Windows 95, SimCity wasn’t working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn’t free memory right away. That’s the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95.

https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...

What's preventing a compromised kernel on one core from hijacking the other cores? This doesn't seem like much of a security boundary

Nothing prevents it if you achieve code execution. But where it helps is scenarios like syscall / memory mapping exploits where a user process can only affect resources attached to their current kernel. For example https://dirtycow.ninja/ would have a limited scope.

My limited understanding is. There is no safe subset (That's what was just discontinued, profiles are the alternative.)

And C++ code simply doesn't have the necessary info to make safety decisions. Sean explains it better than I can https://www.circle-lang.org/draft-profiles.html

The analysis you link to is insufficient.

E.g., the first case is "Inferring aliasing". He presents some examples and states, "The compiler cannot infer a function’s aliasing requirements from its declaration or even from its definition."

But why not?

The aliasing requirements come directly from vector. If the compiler has those then determining the aliasing requirements of those functions is straightforward.

Now, maybe there is some argument that a C++ compiler cannot determine the aliasing requirements of vector, but if that's the claim, then the paper should make it, and back it up.

The paper continues in the same vein in the next section, as if the lifetime requirements of map and min cannot be known or cannot bubble up through the functions that call them.

As written, the paper says almost nothing about the feasibility of static analysis of C++ to achieve safety goals for C++.

I imagine it's (implicitly?) referring to avoiding whole-of-program analysis.

For example, given a declaration

  int* func(int* a);

What's the relationship between the return value and the input? You can't know without diving into 'func' itself; they could be the same pointer or it could return a freshly allocated pointer, without getting into the even more esoteric options.

Trying to solve this without recursively analysing a whole program at once is infeasible.

Rust's approach was to require more information to be provided by function definitions, but that's new syntax, and not backwards compatible, so not a palatable option for C++.

> avoiding whole-of-program analysis

Why, though?

Perhaps it's unfeasibly complex? But if that's the argument, then that's an argument that needs to be made. The paper sets out to refute the idea that C++ already has the information needed for safety analysis, but the examples throw away most of the information C++ does have, without explanation. I can't really take it seriously.

In general, there are three reasons to avoid whole program analysis:

1. Complexity. This manifests as compile times. It takes much longer.

2. Usability. Error messages are poor, because changes have nonlocal effects.

3. Stability. This is related to 2. Without requirements expressed in the signature, changes in the body change the API, meaning keeping APIs stable is much harder.

There’s really a simple reason why it’s not fully feasible in C++ though: C++ supports separate compilation. This means the whole program is not required to be available. Therefore you don’t have the whole program for analysis.

It's not even required for the information to be present at link time; C/C++ doesn't require the pointer to always be owned or not-owned, it's valid for that to be decided by configuration loaded at runtime. Or for it to be decided at random.

Trying to establish proofs that the pointer is one way or the other can't work, because the pointer doesn't have to be only one or the other.

The fact that you then have to treat the pointer one way or the other is a problem; if you reduce the allowed programs so that the pointer must be one of the two that's a back-compat hazard. If you don't constrain it, you need to require additional information be carried somewhere to determine how to treat it.

If you do neither, you don't have the information needed to safely dispose of the pointer.

Local reasoning is the foundation of everything formal (this includes type systems) and anyone in the type-system-design space would know that. Graydon Hoare (ex-rust dev) wrote a post about it too (which links to another great without-boat's post in the very first line): https://graydon2.dreamwidth.org/312681.html

The entire point of having a static-type-system, is to enable local reasoning. Otherwise, we would just do whole program analysis on JS instead of inventing typescript.

The Profiles authors are the ones claiming this uses local analysis only: https://news.ycombinator.com/item?id=41942126

They are clear that Profiles infers everything from function types and not function bodies. Obviously that won't work, but that's what they say.

In that post (I think your own?) it says, "Local analysis only. It's not looking in function definitions."

But local analysis means analysis of function definitions. At least it does to me. I can't think of what else it could mean. I think there must be some aspect of people talking past each other here, using the same words to mean different things.

Further, I don't think local analysis of the code comprising a function means throwing away the results of that analysis rather than passing it up the line to the analysis of callers of the function. E.g., local analysis of std::sort would establish its aliasing limitations, which would be available to analysis of the body of "f1" from the example in the paper (the results of which, in turn, would be available to callers of f1).

Now, I don't know if that's actually feasible/workable without the "heavy" annotation that C++ profiles wants to forbid. That's the key question to me.

  template<typename _RandomAccessIterator>
    _GLIBCXX20_CONSTEXPR
    inline void
    sort(_RandomAccessIterator __first, _RandomAccessIterator __last)
    {
      // concept requirements
      __glibcxx_function_requires(_Mutable_RandomAccessIteratorConcept<
     _RandomAccessIterator>)
      __glibcxx_function_requires(_LessThanComparableConcept<
     typename iterator_traits<_RandomAccessIterator>::value_type>)
      __glibcxx_requires_valid_range(__first, __last);
      __glibcxx_requires_irreflexive(__first, __last);

      std::__sort(__first, __last, __gnu_cxx::__ops::__iter_less_iter());
    }

That's the definition of std::sort. What aliasing information can be gleaned from local analysis of the function? Absolutely nothing.

Maybe, but the first one was so incredible, why not play it first?

It did remind me of that. Tom7 is a treasure

ty is already in the same repo as ruff, so integrating seems likely

Yeah this is the third programming language named Bolt that I'm aware of

I'm aware of 4 now. Here are the other 3:

Bolt: a language with in-built data-race freedom! (recent discussion: https://news.ycombinator.com/item?id=23122973) - https://github.com/mukul-rathi/bolt

Bolt: A programming language for rapid application development - https://github.com/boltlang/Bolt

BOLT: a programming language that was desinged for begining programmers who have never seen code before in their life - https://sourceforge.net/projects/boltprogramming/files

I'm very much in favor of authors choosing unique names for programming languages because there's still plenty of good names up for grabs without having to step on someone's toes. If the project is dead, that's one thing; the data-race one was a research project and hasn't had any activity in 5 years. BOLT last modified in 2014.

But beariish/bolt and boltlang/bolt were started in the same year and are still under active development. With boltlang/bolt obviously snagging the namespace first, I think they should have claim to the name for now. That said, neither seems to have registered any domains, so whoever gets bolt-lang.org/com/net first will probably have an easier time defending a claim.

Not to mention the facebook after compilation optimizer called bolt.

> we don't want vtables

Then don't use virtual functions. Then there will be no vtables.

You might have known that already, but in general I'm surprised how many engineers think that all C++ classes have vtables. No, most in fact do not. C++ classes generally have the same memory layout as a C struct as long as you don't use virtual functions.

Minimum reputation to submit might help

How do I gather reputation to submit without being able to submit something?

Probably the same as in any other high-trust human interaction: you have to have someone on the inside introduce you and vouch for you.

Google exposes serial Serial over the SBU pins on all the Pixel devices

What are the effective implications of this?

It's just a UART; you can use the UART to debug the device in various ways.

On Pixel devices, the UART is not configured or brought up by default in locked production mode (as things should be), but by unlocking the device and then using `fastboot oem uart enable` you can flip the bits to turn it on. On early Pixel devices it was on the headphone jack and on newer ones it's on the SBU pins.

By default I think it's still configured as the kernel console in the kernel command line, so once it's enabled it will show the kernel debug output and present a TTY. But of course you can subsequently configure it to do whatever you'd want a UART for: kgdb for kernel-debugging, earlier stuff in the bootloader, and so on.

So, the implications are just: there's a convenient debugging interface available to you that turns on if you unlock the device and ask for it.

On Chromebook devices there's a more complicated and fancy debugging system where the SBU pins can be muxed to the security processor's USB host interface by presenting a debug cable called a SuzyQ, which presents a whole suite of debugging facilities. This used to be used quite frequently for unbricking purposes.

On the newer pixel phones (starting with the ones containing the titan chip) you can also mux the SBU pins to the security chip USB interface with "fastboot oem citadel suzyq".

And BTW, the SuzyQ cable is nothing more then two pull up resistors and a USB hub connected to the normal usb D+/D- pins on one port and the SBU pins on the 2nd port. Nothing fancy about it, people have even made their own (minus the hub) by soldering some wires and resistors to a usb-c breakout board. Google has also published the schematics for it:

https://www.chromium.org/chromium-os/ccd/951-00273-01_201806...

Been wanting to play with the citadel interface. Last time I looked at it there was 0 public information, but that was years ago. And if there still isn't, then it'll be a good excuse to RE

Also, the titan chip has been around since the Pixel 3 I believe, so "newer" might be a strong word :)