If your wine is made by the founder of Cypress Semiconductors, does that make it a #SPARC-ling wine? (Cypress built the first full-custom SPARC processor). #SunMicrosystems#ClosDeLaTech#TJRodgers
OTD 1983: #SunMicrosystems announces product line with 68010 processors, 4.2BSD UNIX, and 10Mb Ethernet. Until that time, it was 68000s with V7 UNIX and 3Mb Ethernet.
A new “Unlearn podcast” just posted with a discussion between me and Barry O’Reilly that covers some of my early career including #SunMicrosystems and later work at #AWS and the Green Software Foundation on #sustainability. Barry is an excellent interviewer and the production is also really nicely done. I do a bunch of podcast interviews but this was a particularly good one. https://overcast.fm/+RuB6rgpEo
My 13 year old HP Microserver N40L finally died. Luckily, I had a new (8 year old) Gen8 one standing by. Moved the HDDs, did a ZFS import, and up we go! Thank you, #ZFS! #SunMicrosystems#Ubuntu
In 1990, #SunMicrosystems held an internal #VisionQuest contest, challenging employees to imagine the business/technology of Sun 4 to 10 years out. @stoltz unearthed a CD with the entries - 85 of them! I've managed to convert most of them to readable PDFs (but not my entry :-() I'll be posting some observations with the #VisionQuest tag. Some of the predictions are really off the wall, others are spot-on.
What the history of OpenBoot, Phrack, Mudge & Solaris, can teach us about the wisdom (or not) of Apple’s building their iPhone security debugging-backdoor-NSA-hack thing
In the days before people really, really, cared about security — when it was more amazing that mainstream computers worked at all rather than that they offered falsifiable guarantees about privacy and integrity, and most of all in the days before hackerdom decided that it would be great if all the world’s computation ran on “…surely 640Kb is enough for anyone?” glorified MS-DOS personal computers rather than on architectures specifically designed to carry the weight of “big data”… back in those days there was the concept of a monitor.
By monitor we don’t mean VDU nor LCD screen, but instead that what you considered to be your entire computer operating system was something which could be paused, inspected, poked, amended, restarted or halted, all by a little parasitic computer system which probably polled the device tree and booted it up in the first place. The consequence of the monitor was that — beyond being a mere “boot loader” — you were essentially running your entire operating system kernel under a live debugger on a 24×7 basis.
This “debugger” was the monitor; sometimes it was separate hardware, sometimes it was just a firmware-level subsystem with which you could interrupt your operating system at any point, and call back into. At Sun Microsystems (in particular, but much the same was available elsewhere) the monitor evolved into a complete and flexible little solution called OpenBoot, which subsequently became a PCI standard (it is/was(?) even in MacOS) and it was massively powerful.
Unfortunately: with great power comes great responsibility, which (per the first paragraph) people were not really aware of, yet.
Fire up the trusty OpenBoot system via L1-A and get the pointer to thecred structure via :ok hex f5e09000 18 + l@ .f5a99858ok goNow, get the effective user id byok hex f5a99858 4 + l@ .309 (309 hex == 777 decimal)ok goOf course you want to change this to 0 (euid root):ok hex 0 f5a99858 4 + l!ok gocheck your credentials!Alliant+ iduid=777(mudge) gid=1(other) euid=0(root)
tl;dr — press some keys, type a magic incantation in Forth and you become “root”
Let’s just say that OpenBoot was a very powerful and essential medicine… but that provision of that power caused security side-effects/issues that were not going to go away in any short period of time. An excellent little white paper from GIAC provided a synopsis and context from a few years later, in 2001.
The technique of elevating user privileges by manually editing system runtime memory is an exploit that can be used to subvert all operating system security measures. This vulnerability is not operating system platform specific and exists in all computer hardware that utilizes a programmable firmware component for hardware control and bootstrapping procedures. This paper will explain this vulnerability as a class of exploit and utilize the SUN Microsystems’ OpenBoot programmable ROM (PROM) and Solaris as a technical example.
Speaking as one of the people who had to clean up the mess: we/Sun Microsystems should have done a lot more to mitigate the ability of people to get at this powerful medicine; this issue was significant amongst others which drove Sun’s internal security community to create and force the adoption of the “Secure By Default” initiative, and to formalise customer provision and promote adoption of the Solaris Security Toolkit which (amongst many other configuration changes) locked-down several different routes by which the OpenBoot monitor could be exploited.
From the perspective of 2023: this all should have happened 5, perhaps 10 years before Mudge’s posting, but there was neither the corporate will — nor customer will/expertise — to address the matter at that time.
This might sound silly, but I installed virt-manager to make things a little easier when using qemu, then created a new virtual machine with debian 12 on it... then installed qemu on that.
The actual reason for this is to make github account separation a little easier...
If you get virt-manager set up properly, it definitely makes using qemu easier, though. I practically just had to tell it to make a new virtual machine using this iso with this much memory and this big of a hard drive, and it was right at the debian install screen. (Set it up with xfce...).
Main tricky parts were that I had to install libvirt first, make myself a member of the libvirt user group, enable the service, and install dnsmasq. Not great, but could've been worse...
Used debian on the virtual box just for a little variety. I like to keep my hand in on different distributions a bit.
@SweetAIBelle given #Oracle's hostility towards #FLOSS and blatant disregard towards commitments done by #SunMicrosystems when they were (sadly against everyone but #FTC & @EU_Commission 's decisions) allowed to absorb #Sun I think that is sadly more necessary than ever before.
Were it not for the absurdly high cost of electricity in Germany (~€0,33/kWh) I would've already converted several Workstations into Servers running #ProxMox.
I make due with some hp t620 #ThinClients that are fanless…
#Suntember#NFS History: Architecture diagram drawn at the 1st (and only?) NFS architecture offsite, sometime in 1983. It has held up well. #SunMicrosystems