muricula

Some folks may be interested in the Armv9 Scalable Matrix Extensions which appear to do something very very similar. https://community.arm.com/arm-community-blogs/b/architecture...

At a glance, the debugger user interface looks much nicer than gdb's terminal ui. How tightly coupled is the debugger interface to the emulator/debugger engine? How much work would it be to plug in a different debugger, say lldb or gdb, into the ui instead of blink?

I think the user experience of cli debuggers is generally somewhat dreadful when compared to their gui cousins -- they seem to display a much narrower view of what's going on. Could the big blinkenlights debugger view be useful outside of blink itself?

Why would x86 L1 be limited by the page size? The cache works at 128 byte granularity. If it's too big it might increase tlb pressure I suppose, but it makes sense that increases in L1 would be best accompanied by increases in tlb size.

If you're going to port it to a different architecture, do arm64 or risc-v. Don't waste your time learning about the quirks of a processor lineage which has compatibility with features meant to solve problems from the 70s, like segmentation for example.

If you do want to do x86_64, off the top of my head by rough order where you will encounter things:

0. bootstrapping the kernel either gets more complicated or easier based on whether you start in 32 bit mode or 64 bit mode with UEFI. Just start from UEFI and save yourself the headache.

1. The gdt (segmentation table) format changes

2. The tss (another segmentation table) format changes

3. The idt (interrupt table) format changes

4. The ABI (application binary interface, calling convention mostly) changes, leading to a ton of subtle changes to the asm, much deeper than just the register width

5. The page table format changes.

6. Modern processors kick off sibling cores slightly differently. That's not really a 32->64 bit thing but is good to keep in mind.

7. I didn't look to see how they implement their syscall path, but you want to have your kernel ABI be the sysenter instruction, and not say int 0x80. It will simplify your life

> Has corporate America never had layoffs?

Anyone who entered the tech industry in past decade+ has never experienced layoffs at this scale before. Young techies have experienced good times and high salaries. And the transition was quick -- just two quarters ago big companies were hiring techies by the hundred, now they're laying them off by the thousands. A lot of posters here assumed that in the worst case if their current gig failed they could go work on boring software for a year or so before finding something new, but now there's a lot more competition for that plan B job. And heaven help you if you're on a visa, have a health problem, or have a family -- could you be laid off next, and if so where do you go?

Re the http endpoint, that's well and good, it just requires serialization and deserialization to a different protocol at the endpoint, which the docs led me to believe you wanted to avoid.

There is probably an opportunity here to do interesting work around authenticating and validating computations from remote clients.

A word of caution -- javascript engines routinely get hacked, and once attackers can execute native code in the engine process they can call syscalls and have all of the rights of the underlying process. It may be useful to have some form of sandboxing of the language runtime for clients exposed to the internet or intranet. Additionally, Java & Ruby web servers routinely suffer from code injection when deserializing objects, which it seems like your language may be prone to as well.

How does the runtime manage different levels of trust between clients? How does the language grapple with code injection vulnerabilities? If I want to be able to receive data from an untrusted entity, but not code, how do I make sure they're not submitting code to my server to unpack and execute?

Spectre does not require changing the CPU's microcode. You just need to be able to run native code or even javascript. https://security.googleblog.com/2021/03/a-spectre-proof-of-c... https://leaky.page/

Wannacry used the exploit from EternalBlue to create one of the most famous ransomware worms in recent memory, and wasn't the only malware to leverage that one exploit: https://arstechnica.com/information-technology/2019/05/etern... https://en.wikipedia.org/wiki/WannaCry_ransomware_attack

Despite lots and lots of POCs, I haven't seen attackers use spectre in the wild yet. Maybe sophisticated actors are using it but they haven't been caught yet, or more likely they just use more traditional and reliable ways to get info leaks. But if traditional info leaks dwindle, they may turn to speculative execution attacks.

There are two parts to making chips: architecture (design) and process (how it's manufactured). Intel does both but eg Apple only does design and outsources manufacturing to other companies.

There are lots of different chips ranging from slow, energy efficient, and cheap microcontrollers, to fast, energy hungry, and expensive high performance computing clusters. Intel makes the fast ones, and had the fastest chips from the late 1990s to the mid 2010s. Since then, a Taiwanese company has had the fastest chips which go into iPhones, Nvidia graphics cards, and AMD cpus.

Building a fab (manufacturing plant) to make the fastest chips which require features shorter than 7nm (billionths of a meter!) requires billions of dollars in up front investment. It's mass scale manufacturing at some of the lowest levels anything has ever been created at.

The US gov't is afraid that company which makes the fastest chips in Taiwan (which is not recognized as an independent country, but is effectively self governing, but China claims is theirs, it's complicated yes), could be under Chinese control some day. The Military Industrial Complex don't want the US tech sector or US defense tech to be beholden to China, and US companies (Intel) want government funding to build expensive factories. Thus the CHIPS act.

Iran gets trotted out as a strawman in these arguments, but its government is really quite democratic compared to many US allies which have the mere trappings of democracy painted on a dictatorship. Iran has an elected president, and a parliament and multiple parties. As I understand it, the biggest issue with the government as a functioning democracy is that the unelected supreme council can prevent candidates from running and and dissolve parties. I don't mean to defend its actions against protestors right now, which I believe are heinous, and the government is lacking in respect for many human rights, but as a strawman for absolute dictatorship it's a very poor choice. Democracy is a spectrum, Iran is definitely on the spectrum, and if we Americans look in the mirror and think deeply about the structure of our government, we might find out that we're a lot closer to Iran on that spectrum than we were taught in school.

https://en.wikipedia.org/wiki/Government_of_the_Islamic_Repu...

Like your internet service provider you already have??

The article says whether a language runtime like v8 is a stronger security boundary than a hypervisor is a matter of debate, however v8 has boatloads of CVEs and the further isolation of browser sandboxes has been a driving factor in OS development for nearly two decades. Meanwhile, multiple Fortune 500 companies bet their multi-billion dollar cloud businesses on the security of their hypervisors.

So when the author links to a confused HN thread about whether the v8 runtime is a security boundary and says "looks like there's debate", it makes the article look like a joke.

Seems fake. The image in the header appears to have been passed around the internet and reused, but may originate here in 2013: https://web.archive.org/web/20130912050353/http://www.pastho...

I'm fairly sure that checkm8 doesn't affect apple silicon macs.

Process and architecture are mostly independent.

Node process is determined by the physical manufacturing. Architecture is determined by the design templated on during manufacturing. You could make an arm core on an intel process (which I think even happens in some of their testing phases). So yes.

To quote the last sentence of the article: > Other major figures in the case settled years ago, including the builder and the owner of the private lockups and their companies, in payouts totaling about $25 million.

PAC (pointer signing) & Branch Target Identification are not available on 32 bit arm chips, and judging by the assembly in the blog post the Titan M is a 32 bit chip.

In a sense, finding security bugs is a very specialized QA sub-discipline, which often requires a far deeper understanding about security than many QA engineers or developers possess. However, there is also a part of that organization which does feature work to systemically address the kinds of security issues they find.

Also, many large organizations like MS don't have many QA teams, preferring to push QA tasks onto developers, but still need specialized security teams. If you dig into the deep history of morse, they barely escaped being sacked when MS laid off the QA org circa 2017.

(I used to work on that team, but now work at another company doing a similar job)

Everything you said about memory space & bandwidth is 100% on point.

However: arm arch 32 has 14 general purpose registers (including the link register). arm arch 64 has 31 general purpose registers (also including the link register).

I also doubt there are real power savings in modern out of order processors. The few transistors saved in the register file and ALUs are just dwarfed by everything else. Heck, look at how much of a modern soc like the M1 is used by the compute complex compared to everything else.

yup :P

What is this language's approach to memory safety? Does it guarantee there can never be out of bounds accesses, use after frees, double frees, or other memory corruption errors? Anything which talks to attackers over the internet is a prime target for these sorts of attacks.

A zero day bug in the pdf parser or javascript engine of your browser. Such bugs are common enough that the North Korean military is believed to use them to gather intelligence and for theft, but also are rare enough that they're going to use them on just anyone.

I have debugged the kernels of Windows, Linux and now iOS using internal tools. Windbg generally works, and is far superior to the equivalent tools for other kernels. Like vim it has a baroque syntax and a steep learning curve, but it also has a gui with big buttons to compensate. Yeah, you can get yourself in bad situations, especially in early boot, but I miss it.

That's what the ios sandbox provides. Heck, the tools arm64 gives you to isolate VMs are awfully similar to the tools they give you to isolate processes. VM escapes aren't too different than sandbox escapes.

Encrypted memory isn't part of arm yet, I was holding out hope with armv9 "realms" but not so.

Oregon House is actually in California: https://en.wikipedia.org/wiki/Oregon_House,_California

It's a confusing name.

visual studio online is what it was called internally, the marketing may have changed. It's okay, and is what was/probably still is used at MS internally to develop windows.

Here's an internal ABI doc which escaped Redmond at one point: http://www.openrce.org/articles/files/jangrayhood.pdf I believe there were other ABI docs but the official version of that was what I was given.

Windows and Darwin (MacOS) were originally designed to be hybrid kernels, but compromised by allowing more and more stuff into kernel space until they were the monolithic kernels we know today. Changing code built up over 20-30 years while maintaining compatibility, security, and performance guarantees is not something which could be accomplished in a couple of months.

The UN defines genocide as: (a) Killing members of the group; (b) Causing serious bodily or mental harm to members of the group; (c) Deliberately inflicting on the group conditions of life calculated to bring about its physical destruction in whole or in part; (d) Imposing measures intended to prevent births within the group; (e) Forcibly transferring children of the group to another group.

Killing members of a group is not necessary for something to be genocide. I realize the legal meaning of genocide is different than how some people generally use the word, but I don't think your objection holds up to scrutiny.

https://www.un.org/en/genocideprevention/documents/atrocity-... https://en.wikipedia.org/wiki/Genocide_Convention#Definition...