Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MIT Scheme on Apple Silicon

kennethfriedman.org

Post reply on HN
Print view View original

41–50 of 87 posts

Re: MIT Scheme on Apple Silicon

#41

Post by andrewxdiamond »

maratc wrote: post #16
smoldesu wrote: post #15

Earlier quoted context omitted.

Well, let's see. Is there a way for me to run a Java program as native machine code? Or is the code that I'm executing still a runtime that interprets a program?

The vast majority of the programs in the world are written in Javascript, and there's no way for you to "run" them if by that you mean "natively".

> The vast majority of the programs in the world are written in Javascript

Where is this coming from? What about the literal thousands and thousands of programs on your OS right now? Or the thousands of systems that power large corporations that predate JavaScript popularity?

Sure the language is popular right now, but software development has a much longer history than the last 10 years

Re: MIT Scheme on Apple Silicon

#42

Post by astrange »

spijdar wrote: post #32
usmannk wrote: post #29

Earlier quoted context omitted.

Wow really? A common intro to security exercise (think CTFs and university courses) is to write increasingly complicated C programs that leverage W&X. Classic buffer overflow into the stack kind of stuff. On M1 it’s now impossible to exploit even a self-compiled toy in this way?

Basically, yeah. In addition, the usual way to bypass W^X memory, using ROP chains, is also mitigated by the pointer authentication the M1 implements. It's not bullet proof, but it prevents most of the old exploit methods from working at all. You'd need to throw up a VM on an M1 Mac to learn much this way (although that'd be ideal anyway, to get an environment without other protections like ASLR) I know at least Open…

Pointer authentication isn’t in 3rd party processes though, only system ones. (or maybe it’s available but optional, I forget)

Re: MIT Scheme on Apple Silicon

#43

Post by my123 »

astrange wrote: post #42
spijdar wrote: post #32

Earlier quoted context omitted.

Basically, yeah. In addition, the usual way to bypass W^X memory, using ROP chains, is also mitigated by the pointer authentication the M1 implements. It's not bullet proof, but it prevents most of the old exploit methods from working at all. You'd need to throw up a VM on an M1 Mac to learn much this way (although that'd be ideal anyway, to get an environment without other protections like ASLR) I know at least Open…

Pointer authentication isn’t in 3rd party processes though, only system ones. (or maybe it’s available but optional, I forget)

> Pointer authentication isn’t in 3rd party processes though

Still isn’t, because the arm64e ABI isn’t stable. As such, any binaries not bundled with the OS, including Apple applications, use the arm64 ABI without pointer authentication.

You can use -arm64e_preview_abi as a boot argument to enable arm64e support for non-OS bundled processes.

Note that however the arm64e binaries that you compile might not work on future macOS releases.

Re: MIT Scheme on Apple Silicon

#44

Post by my123 »

Wowfunhappy wrote: post #26
simonh wrote: post #17

Earlier quoted context omitted.

> Apple Silicon has a (mostly) hardware translation layer… I can’t imagine what you mean by this, Rosetta 2 is a binary translation system implemented in software, based on QuickTransit. There are a few features implemented in Apple Silicon to make translation easier and more efficient, such as supporting Intel memory ordering, but thats about it. I think it’s reasonable to worry about how long rosetta2 will be avail…

I can't say what Apple will do, but I'm really hoping they'll keep Rosetta 2 around for longer than Rosetta 1. For starters, the Mac became a lot more popular in the Intel era than it ever was while on PPC, so there's a much larger quantity of legacy software that Apple would be cutting off. Secondly, the overall user experience of running apps via Rosetta 2 seems to be a lot better than Rosetta 1. And for Apple, Ros…

For Rosetta (1), QuickTransit was bought up by IBM. Rosetta disappeared not very long after that.

Re: MIT Scheme on Apple Silicon

#45

Post by my123 »

monocasa wrote: post #39
GeekyBear wrote: post #38

Earlier quoted context omitted.

My understanding is that Rosetta 2 is based on LLVM. Even the company that made QuickTransit is gone now, having been bought out by IBM a decade ago.

My understanding is that Apple hired a lot of the staff of Transitive, and had a more or less do whatever you want license with source access. Ad that the AOT mode is based on LLVM, but the JIT piece is still pretty core to the design (hence why other JITs run well on top of it).

It’s not based on LLVM, that’s way too heavy for the use case.

The same backend is used for AoT and JIT compilation. It uses a custom lightweight IR that’s really close to x86 itself, with a big focus towards reducing translation times.

Rosetta 2/Cambria was fully written in-house.

Re: MIT Scheme on Apple Silicon

#46

Post by bigdict »

usmannk wrote: post #29
spijdar wrote: post #14

Earlier quoted context omitted.

MacOS on the M1 processor is the first to use, and require, the W^X bit in memory, meaning that pages of memory are either writable, or can be executed from, but not both. MIT Scheme's front page says this is fundamentally incompatible with their design, and therefore it won't build. When running in the emulator, this requirement would be relaxed for compatibility reasons. There is an escape hatch for writing JIT com…

Wow really? A common intro to security exercise (think CTFs and university courses) is to write increasingly complicated C programs that leverage W&X. Classic buffer overflow into the stack kind of stuff. On M1 it’s now impossible to exploit even a self-compiled toy in this way?

Offtopic, but can you recommend such a course?

Re: MIT Scheme on Apple Silicon

#47

Post by bigdict »

mark_l_watson wrote: post #22

I got MIT Scheme running on my M1 MacBook Pro about 6 months ago when I bought the book "Software Design for Flexibility" and although I can't find my notes for that, I think I remember building from source natively, not via Rosetta - but I may remember incorrectly. I also remember it taking a while to get Gerbil Scheme running on M1.

How did you like the book?

Re: MIT Scheme on Apple Silicon

#48

Post by nneonneo »

esprehn wrote: post #35
spijdar wrote: post #32

Earlier quoted context omitted.

Basically, yeah. In addition, the usual way to bypass W^X memory, using ROP chains, is also mitigated by the pointer authentication the M1 implements. It's not bullet proof, but it prevents most of the old exploit methods from working at all. You'd need to throw up a VM on an M1 Mac to learn much this way (although that'd be ideal anyway, to get an environment without other protections like ASLR) I know at least Open…

Windows has had this enabled by default for a long time: https://docs.microsoft.com/en-us/windows/win32/memory/data-e... There's a per program exception list to handle legacy programs though.

Windows DEP only applies W^X (more accurately, !X) to the default stack and heap; programs can still freely allocate new memory as PAGE_EXECUTE_READWRITE if they want RWX memory.

macOS W^X on Apple Silicon, however bans RWX memory outright, making it impossible to have a page in memory that is simultaneously writable and executable. Instead, if you want to be able to write instructions to a page and later execute them (e.g. for JIT compilation), you have to (1) have a special entitlement (or opt out of the Hardened Runtime), (2) map your memory with a special MAP_JIT flag, and (3) call special mprotect-like functions to toggle the protection between RW and RX every time you want to modify the code.

There does, however, seem to be a bit of a loophole: the JIT protection flags are applied per thread meaning that in principle one thread could have the page RW while another has it RX.

Re: MIT Scheme on Apple Silicon

#49

Post by ebruchez »

smoldesu wrote: post #15
moron4hire wrote: post #12

Earlier quoted context omitted.

No, it's not a stretch at all. This is just nerd contrarianism.

Well, let's see. Is there a way for me to run a Java program as native machine code? Or is the code that I'm executing still a runtime that interprets a program?

Yes there is, although it's not in widespread use yet. [1]

For Scala, there is, separately, Scala Native. [2]

Both have ahead-of-time (AOT) compilers that compile down to the target architecture.

[1] https://www.graalvm.org/reference-manual/native-image/ [2] https://github.com/scala-native/scala-native

Re: MIT Scheme on Apple Silicon

#50

Post by alwillis »

Wowfunhappy wrote: post #26
simonh wrote: post #17

Earlier quoted context omitted.

> Apple Silicon has a (mostly) hardware translation layer… I can’t imagine what you mean by this, Rosetta 2 is a binary translation system implemented in software, based on QuickTransit. There are a few features implemented in Apple Silicon to make translation easier and more efficient, such as supporting Intel memory ordering, but thats about it. I think it’s reasonable to worry about how long rosetta2 will be avail…

I can't say what Apple will do, but I'm really hoping they'll keep Rosetta 2 around for longer than Rosetta 1. For starters, the Mac became a lot more popular in the Intel era than it ever was while on PPC, so there's a much larger quantity of legacy software that Apple would be cutting off. Secondly, the overall user experience of running apps via Rosetta 2 seems to be a lot better than Rosetta 1. And for Apple, Ros…

And for Apple, Rosetta 2 was developed in-house and doesn't require continuous licensing fees to keep around (not that I'm particularly sympathetic to Apple's pocketbook.)

I don't think any of those things matter; Apple will stop supporting Rosetta 2 as quickly as they can. They announced the transition to Apple Silicon will be two years and unless something unforeseen happens, that's what it's going to be.

I suspect that Rosetta 2 won't be available for new Apple Silicon Macs running macOS five years from now.

Of course, no matter how many years in advance Apple warns that a particular technology is going to be deprecated, that never stops people from complaining vociferously when it happens.

A great example is 32-bit apps, where Apple gave something like an 8-year heads-up that 32-bit apps were going away, which happened a few years ago but it's not hard to find threads on HN where people are still complaining about it.

Post reply on HN