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

Linux is an interpreter

astrid.tech

Post reply on HN
Print view View original

41–50 of 65 posts

Re: Linux is an interpreter

#41

Post by lolsowrong »

fc417fc802 wrote: post #38
lolsowrong wrote: post #33

Earlier quoted context omitted.

Most of the time. But sometimes, no. See ATL thunk emulation (last I checked, still alive in the windows kernel) and ntvdm handling of the BOP pseudoinstruction. See also: Jazelle DBX. Hell, on modern x86 processors, many “native” instructions are actually a series of micro-ops for a mostly undocumented and mostly poorly understood microcode architecture that differs from the natively documented instruction set. It’s…

Aren't all of them microcoded? Some years back root was achieved on a line of intel processors and new instructions implemented as proof of concept. There's an academic paper, citation not immediately to hand.

I saw the paper from Google last year and thought something in it aligned with not everything running through the microcode engine, though I could be wrong.

Re: Linux is an interpreter

#42

Post by fc417fc802 »

lolsowrong wrote: post #41
fc417fc802 wrote: post #38

Earlier quoted context omitted.

Aren't all of them microcoded? Some years back root was achieved on a line of intel processors and new instructions implemented as proof of concept. There's an academic paper, citation not immediately to hand.

I saw the paper from Google last year and thought something in it aligned with not everything running through the microcode engine, though I could be wrong.

Might well be the case. I don't think I'm familiar with the paper you're referring to; any chance of at least a vague description?

Re: Linux is an interpreter

#43

Post by fc417fc802 »

saagarjha wrote: post #35
lolsowrong wrote: post #33

Earlier quoted context omitted.

Most of the time. But sometimes, no. See ATL thunk emulation (last I checked, still alive in the windows kernel) and ntvdm handling of the BOP pseudoinstruction. See also: Jazelle DBX. Hell, on modern x86 processors, many “native” instructions are actually a series of micro-ops for a mostly undocumented and mostly poorly understood microcode architecture that differs from the natively documented instruction set. It’s…

Jazelle and micro-ops are not interpreters, they are executed in hardware.

An interpreter implemented in hardware is still an interpreter. Hot take, all machine instruction sets are scripting languages and LLVM is a transpiler.

Re: Linux is an interpreter

#44

Post by trynumber9 »

fc417fc802 wrote: post #38
lolsowrong wrote: post #33

Earlier quoted context omitted.

Most of the time. But sometimes, no. See ATL thunk emulation (last I checked, still alive in the windows kernel) and ntvdm handling of the BOP pseudoinstruction. See also: Jazelle DBX. Hell, on modern x86 processors, many “native” instructions are actually a series of micro-ops for a mostly undocumented and mostly poorly understood microcode architecture that differs from the natively documented instruction set. It’s…

Aren't all of them microcoded? Some years back root was achieved on a line of intel processors and new instructions implemented as proof of concept. There's an academic paper, citation not immediately to hand.

Some instructions are microcoded but others take the fast path and avoid the microcode sequencer. Can't patch the latter in microcode RAM.

Re: Linux is an interpreter

#45

Post by tosti »

astralbijection wrote: post #27
tosti wrote: post #22

This article was painful to read because of all the misconceptions. A cpio archive is not a filesystem. Author uses initramfs, which is based on tmpfs. Linux can extract cpio to tmpfs. An archive of files and directories is in itself not a program. Just because something looks similar doesn't mean it's equivalent. Binary programs are executed on the CPU, so if there's an interpreter involed it's hiding in the hardwar…

> An archive of files and directories is in itself not a program. Okay, but you can make the same argument to say that ELF files aren't programs in and of themselves either. In fact, some ELF files are dynamic libraries without an entrypoint, and therefore not actually executable in any meaningful way unless connected to yet another program. If you can accept that some ELF files are executables and some aren't, then…

By that logic, everything is executable. Not entirely wrong, but mostly because of vulnerabilities. Not because of a highly contrived way of using a file format to run a program. You could do the same thing with json or xml.

Re: Linux is an interpreter

#46

Post by lolsowrong »

fc417fc802 wrote: post #42
lolsowrong wrote: post #41

Earlier quoted context omitted.

I saw the paper from Google last year and thought something in it aligned with not everything running through the microcode engine, though I could be wrong.

Might well be the case. I don't think I'm familiar with the paper you're referring to; any chance of at least a vague description?

Can’t find the pdf, but it’s all related to the zentool stuff:

https://github.com/google/security-research/blob/master/pocs...

Tavis spells it out there pretty quickly:

“ The simplest instructions (add, sub, mov, etc) are all implemented in hardware. The more complicated instructions like rdrand, fpatan and cmpxchg are microcoded. You can think of them as a bit like calling into a library of functions written in that RISC-like code.”

Post reply on HN