[ / / / / / / / / / / / / / ] [ dir / asmr / aus / ebola / ita / maka / mexicali / russian / vore ][Options][ watchlist ]

/tech/ - Technology

You can now write text to your AI-generated image at https://aiproto.com It is currently free to use for Proto members.
Name
Email
Subject
Comment *
File
Select/drop/paste files here
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Expand all images

File (hide): 25e8a2b1320cec9⋯.png (269.01 KB, 600x500, 6:5, serverism.png) (h) (u)

[–]

 No.815589>>816178 >>816306 [Watch Thread][Show All Posts]

Is there NOT a single fully open source single board pc with no binary blobs? Or hardware -sans libreboot thinkpads and macbooks- ?

 No.815598>>816697

patent-hymies run semiconductor design, verilogtards don't seem to mind working for 'intellectual property rights advocates', and we put blind faith in 'the system' and 'the hardware' because of

<muh too 'spensive to do it any other way


 No.815602>>815604

I think there is some armshit, but you have to do without graphics acceleration.


 No.815604>>815608

>>815602

im honestly ok with that. its honestly frustrating what hardware industry become


 No.815608>>815642

>>815604

It is, the new amd stuff is great performance wise but fully DRM'd. I hope PowerPC stuff becomes more affordable because everything else is just a losing battle.

Beagleboard seems to be the most freedom friendly single board computer: https://www.fsf.org/resources/hw/single-board-computers


 No.815617>>816336

PC Engines APU2 is allright.


 No.815642

I've been seeing this come up rather frequently; The question of how to escape the hardware botnet, or how to escape x86, as a majority of it is pozzed.

Since your question opened with one about single board comupters, you should take a look at this anon >>815608 's link, and look at the 'serious flaws' section, particularly the beagleboard and some of the allwinners, as they are the ones that are Free as in Freedom, minus the GPU acceleration.

Going into your question about other hardware, other than the libreboot thinkpads and macbooks, let's start with desktop computers. I think this is actually the easier one to do and stay modern.

On the libreboot HCL, https://libreboot.org/docs/hardware/ , there are several desktop and server/workstation options. There's a few C2D and Atom options, which are not optimal, but there are a few really nice looking ones.The KCMA-D8, KFSN4-DRE, and the KGPE-D16 are all AMD Opteron boards that can be librebooted, and there is also the new addition of a certain iMac, which is fully compatible apparently, although it does not yet have instructions on the site. As far as getting away from x86, there is also a very nice option here. The TALOS II workstations https://www.raptorcs.com/content/base/products.html are fully Free, and are potentially going to get RYF certified by the FSF soon. They use OpenPOWER, which is an architecture supported by Debian and Fedora (you could probably make Gentoo work too).

Laptops are where shit gets hard. There don't seem to be many options here outside of the Libreboot Thinkpads and Macbooks, and certainly no good ones outside of x86. You'll just have to settle for CD and C2D processors, although there was that rumor of an x220 exploit, and I saw on their notabug that they may be providing support for Core2Quad.

For other options, I think this is less of a "what can I buy right this second" thing, and more of a "what can I look forward to" thing. There does appear to be a Libre ARM laptop with EOMA68 https://www.crowdsupply.com/eoma68/micro-desktop , but have fun using 1.2GHz and 2GB of RAM. At that point, you might as well be using one of those SBC pcs as your laptop, which is kinda what this is. Same goes for the pinebook https://www.pine64.org/?page_id=3707 it looks nice, but once again it's literally a shitty SBC in a laptop, and in this case, I don't think it's even Libre. Purism looks like something to keep an eye on. While they are not Libre, and thus far only have coreboot and """apparently""" a removal of the ME, they do appear to want to go a step further. A very overlooked page on their site is this one https://puri.sm/learn/freedom-roadmap/ which outlines their goal of going all the way to 100% freedom, and where they are on that road to it.

In any case, RISC-V looks like something else to look forward to. Hopefully someone makes a fully usable computer with it that runs on Free Software, because right now it looks quite promising.


 No.816169>>816173 >>816199

There are some Open Source SBCs, or you can go the FPGA route and build your own.


 No.816171>>816173

Look at the fucking libreboot website there's a bunch of motherboards you dumb stupid asshole


 No.816173>>816179

>>816169

>There are some Open Source SBCs

Like what? Everything based on ARM processors is by definition not open or free whatsoever.

>>816171

Which are 10 years old, ya dumb sperg.


 No.816178

>>815589 (OP)

Because if you release the level of documentation needed to realize that it means anyone can make that exact chip. If you try releasing the specs under a license that doesn't allow anyone to reproduce them, you will get shunned by the freetard audience you sought to gain by releasing them in the first place.


 No.816179>>816180

>>816173

If you want to be free of blobs, backdoors, botnets, etc. you'll have to use old hardware, retard.


 No.816180>>816188 >>816368

>>816179

I do own and use a librebooted Thinkpad x200, but I also don't get why I'm force to old hardware with the resources that are available nowadays.

PowerPC is the proof that there is a market for this stuff, and if trillion of startups can develop their own dumb SBCs, than why isn't possible to combine the two things and have affordable libre-hardware?

It fucking hurts having to deal with nu/tech/ mongrels


 No.816188>>816196

>>816180

>I also don't get why I'm force to old hardware

Because of the people with power over new hardware.

>why isn't possible to combine the two things and have affordable libre-hardware?

It still costs a lot of money to do a fab run of a board as there's a lot of work setting up for it. I'm in embedded and we're white labeling our boards in several products for cost reasons and this is pretty normal across the industry. Startups with VC dollars can afford to build their own boards, freetards cannot.


 No.816196

>>816188

>Startups with VC dollars can afford to build their own boards, freetards cannot.

Lemote laptops seemed to be a newer alternatives to the classic Thinkpads, but their development didn't particularly progress and lacked of decent support.


 No.816199

>>816169

>There are some

The only one appears to be the Libre Tea Computer Card, which hasn't been approved by the FSF yet.


 No.816236>>816243

I want a free as in freedom FPGA computer.


 No.816243>>816262 >>816281

File (hide): dc6c02d7be153e6⋯.png (140.94 KB, 486x626, 243:313, image001.png) (h) (u)

>>816236

what about the programmer, is it free/open?

remember old paper: reflections on trusting trust


 No.816262>>816278

>>816243

reflections on trusting trust tells us that we can't even trust programs with source code.


 No.816278

>>816262

I thought it's about bootstraping in general. You can see and verify the code, but can you trust the compiler? And here can you trust the FPGA programmer? Maybe you can build same code with different compilers and compare the output (and you can even write your own compiler entirely in machine code). But how do you compare the circuits from different FPGA programmers? You probalby need different brands, models, even old and news ones. But checking the circuits, I have no idea how you would do that. Logic probe? Or maybe the programmers can do it...


 No.816281>>816308

>>816243

>The trap doors described in the report were patches to the binary object files of the system. The report suggested a countermeasure to such object code trap doors by having customers recompile the system from source, although the report also notes that this could play directly into the hands of the penetrator who has made changes in the source code. In fact, the AFDSC Multics contract specifically required that Honeywell deliver source code to the Pentagon to permit such recompilations. However, the report pointed out the possibility that a trap door in the PL/I compiler could install trap doors into the Multics operating system when modules were compiled and could maintain its own existence by recognizing when the PL/I compiler was compiling itself. This recognition was the basis several years later for the TCSEC Class A1 requirement for generation of new versions from source using a compiler maintained under strict configuration control. A recent story on CNET news [14] reports that the Chinese government has similar concerns about planted trap doors.

>This suggestion proved an inspiration to Ken Thompson who actually implemented the self-inserting compiler trap door into an early version of UNIX. Thompson described his trap door in his 1984 Turing Award paper [40], and attributed the idea to an “unknown Air Force document,” and he asked for a better citation. The document in question is in fact the Multics Security Evaluation report, and we gave a new copy of the report to Thompson after his paper was published. Thompson has corrected his citation in a reprint of the paper [39].


 No.816306

>>815589 (OP)

There's the Talos II, which is based on IBM's new POWER9 architecture and can run (as yet) Linux and AIX. But it's server-grade, expensive hardware.


 No.816308

>>816281

>This suggestion proved an inspiration to Ken Thompson who actually implemented the self-inserting compiler trap door into an early version of UNIX.

Wait, but weren't later versions of UNIX compiled using the old UNIX compilers? How did Thompson get rid of the trap door?


 No.816336

>>815617

This. I've had a APU1 for a couple of years. Great bits of kit and they run on Coreboot.

They sit somewhere between high-end Pi type boards and low-end mini-ITX in their hardware specs.


 No.816368>>816373 >>816458 >>816480 >>816789

>>816180

The hardware must be reverse engineered. I don't believe for one second POWER/PPC based hardware is free of proprietary embedded firmware. Mac firmware is most definitely not open. ARM SoCs are most definitely not open by design. Not even the RISCV SoCs are 100% free of proprietary firmware. It's a meme status with meme solutions.


 No.816373>>816463

>>816368

The one exception is the new POWER 9 Talos II


 No.816458>>816459

>>816368

>Mac firmware

Macs haven't used power since 2005, and when they did, they actually used OpenFirmware.


 No.816459

>>816458

OpenFirmware is a misnomer. It is not open.


 No.816463>>816514

>>816373

2 Broadcom Gigabit Ethernet ports

1 Microsemi SAS 3.0 controller

Don't forget the firmware embedded on any hard drives you add too. I would like to see a third party security review.


 No.816480>>816489

>>816368

>Not even the RISCV SoCs are 100% free of proprietary firmware

No.


 No.816484

why would it matter?

It's not like you'd understand the code even if it was open source


 No.816489>>816495 >>817249

File (hide): 128eeeeb6f5b401⋯.jpg (1.01 MB, 4859x3239, 4859:3239, SiFive_Arduino.jpg) (h) (u)


 No.816495>>816500

>>816489

http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT2232H.pdf

Can you show me which part of this thing requires any kind of firmware.


 No.816500>>816509

>>816495

I'm not sure that this is the same chip, but in the PDF it states "royalty free drivers" are provided. It is definitely not open by design.


 No.816509>>816550

>>816500

http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT2232C.pdf

This is the chip in the HiFive1 and it makes no reference to any firmware.


 No.816514>>816523

>>816463

>firmware embedded on any hard drives

Definitely a concern. Probably the biggest potential attack vector after ME.

https://hooktube.com/watch?v=0Da6OARhgXk


 No.816523>>816535 >>817426

>>816514

>Probably the biggest potential attack vector after ME

dohoho, no. The ethernet controller is. It's powered even when the computer is off, has been able to listen for magic packets while off since the '90s (Wake-on-LAN), and today has deep connections to the rest of the hardware. I would honestly be shocked if there wasn't already some magic packet supported on Intel's ethernet controllers that runs the payload. Even if there were no Jews it'd still have been a priority for the NSA since Chinese Loongson boards with Chinese-made MIPS processors still often use Intel ethernet controllers and it'd have been incredibly simple to implement. On newer hardware where a lot of the functionality has migrated to the ME, it could even be made to look like a mistake.


 No.816535>>816557

>>816523

Can't you just use USB ethernet instead of on-board one? Or how about PCMCIA/ExpressCard<->USB adapter, if those exist?


 No.816549

Loongsons use AMD chipsets ffs. Doesn't matter if their network card is Intel or Realtek.


 No.816550>>816551

>>816509

Yes, it appears it can operate without EEPROM. It still requires closed drivers to operate and closed software to upload to EEPROM if present. They went to all this trouble to produce an open platform, and it turns out you can't even access it without using a closed IC.


 No.816551>>816733

>>816550

I have no idea what you're talking about here. Link me to the manual you're referring to an also the page number.


 No.816557

>>816535

USB devices have access to your hardware, too. I'm not sure if they're able to be powered when off, though.

Btw, USB ethernet is the shittiest thing in the world, don't use it. I tried shipping those adapters with one of our products and I probably tested a dozen of them from different vendors and they were all garbage in their own special way. Several just clone the whole goddamn chip too and there's no way to tell them apart - same MAC, same USB info, same everything.


 No.816691>>816698 >>816844 >>817248

I don't get this GNU/firmware autism.

When you guys or Libreboot autists sperg out on non-free firmware.

Is it accessible from OS and can be updated this way?

No? Not a problem, glue the chip with epoxy to prevent external flashing and treat it as black box.

Does it load before OS and/or occupies main CPU/RAM registers?

No? Not a problem.

Does it require to execute non-free software n OS level?

No? Not a problem.

Like for example, when you copy a Photoshop.exe or Windows ISO from hard disk to external drive, does it affect your freedoms? Nope. Same thing happens with most firmware, it just loads from EEPROM into the device controller and occupies this device's ram and cpu.

ME and proprietary bootloaders on the other hand, do occupy main system RAM and CPU, run in privileged mode and can do the fuck they wish to do with your OS that loads after, they can do anything from something as simple as evil maid attack to hypervisor-tier attacks on guest.

Stallman though, says if you can't update firmware in any way, and hardware isn't networked then it is fine. Because even rogue firmwares exist, and they can do bad things on OS compatibility levels, mostly through free driver exploits.


 No.816697>>816718

>>815598

>too 'spensive to do it any other way

I don't want to be the current year guy but come one, you can make a cheapo electron microscope nowadays, now all you need is an autist that will peel the die layer by layer with some acids


 No.816698>>816735

>>816691

>Stallman though, says if you can't update firmware in any way, and hardware isn't networked then it is fine

[CITATION NEEDED]


 No.816718>>816726

>>816697

This never came to mind, Is it something worth the costs and labor of doing so? Maybe we can shill the idea to some workers in shenzhen.


 No.816726>>816756

>>816718

Delayering chips and doing RE by microscope for modern chips with billions of gates is pretty expensive.


 No.816733>>816789

>>816551

Did you even bother reading the PDFs you posted?

http://www.ftdichip.com/Drivers/D2XX.htm


 No.816735>>817155

>>816698

https://stallman.org/stallman-computing.html

>if updating software is not a normal part of use of the device, then it is not a computer.


 No.816756>>816782

>>816726

Whats a rough estimate, surely the gains made from monopoly busting would be worth it?


 No.816782

>>816756

... to inspect a billion gates by hand? Who knows. You'd need to build a custom machine vision system for it to be feasible at all. This is large multinational or nation state territory.


 No.816789>>816881

>>816733

That's it? No wonder I was confused, you don't know what you're talking about in >>816368. You complain that The HiFive requires proprietary firmware but that is actually false. The drivers that you linked to are not firmware, they are drivers. These drivers do not get loaded onto the HiFive board, they are intended to be loaded on your development PC, not your development board.


 No.816844>>816927

>>816691

>don't get this firmware

https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf would be a good place to start.


 No.816881>>817250

>>816789

I'll eat crow and admit I was off base with it needing proprietary firmware. You still need to use their drivers to access the device. Unless someone else has an open driver to access it, it's a paperweight.


 No.816927

>>816844

I was expecting another paper from Rutkowska, "State considered harmful".


 No.817155

>>816735

He also says that if said "non-computer" has malicious software you can't replace, that you're better off avoiding the device completely.


 No.817248

>>816691

>Does it load before OS and/or occupies main CPU/RAM registers?

UEFI loads before the OS and stays resident, yes.


 No.817249

>>816489

The ISA itself makes _no_ proviso for the use of ICs which require firmware, but every company that implements it, is free to use whatever ICs they see fit, including ones that use firmware if they so choose. It's up to people to pick the right hardware, as usual.


 No.817250

>>816881

Which is why a lot of companies (except, notably, Realtek) provide data-sheets for engineers looking to write drivers for opensource software, on request. See: Much of the BSDs device trees.


 No.817426>>817432

>>816523

I've been going off Libreboot's guidance, which mentions Ethernet controllers, but doesn't go into much detail. What sort of processing capability do they have? HDD controllers clearly have enough to run sophisticated Kikery.


 No.817432>>817438

>>817426

They can use the host processor today (see: Intel ME WoL) without waking the host OS, so 'unlimited capability'.


 No.817438>>817439 >>817447

>>817432

ME risk is well known and discussed. What I'm asking is, suppose we are able to neutralise ME completely, does the Ethernet controller still present a risk?


 No.817439

>>817438

it's kind of confusing to think about, but every microcontroller and microprocessor in your computer is a vulnerability.

yes the ethernet controller is vector for attack in your and everyone's computer.


 No.817447

>>817438

It's directly connected to the bus. So.. duh?




[Return][Go to top][Catalog][Screencap][Nerve Center][Cancer][Update] ( Scroll to new posts) ( Auto) 5
63 replies | 2 images | Page ???
[Post a Reply]
[ / / / / / / / / / / / / / ] [ dir / asmr / aus / ebola / ita / maka / mexicali / russian / vore ][ watchlist ]