/robowaifu/ - Why consider alternative CPU architectures for secure systems?

Name
Subject
E-mail
Message	Max message length: 6144
Files	Drag files to upload or click here to select them Maximum 5 files / Maximum size: 20.00 MB

Spoiler images
Password	(used to delete files and postings)
Use bypass

Why consider alternative CPU architectures for secure systems? Robowaifu Technician 07/25/2020 (Sat) 13:55:25 No.4506

Hello Anons, wanted to share some info and perhaps make you think about what you should compute with. x86/amd64 -Proprietary ISA (Instruction Set Architecture) This means to get enough low-level detail requires signing non disclosure agreements (NDA). Even then, they might not disclose all the available commands (see Breaking x86 video below). If you cannot trust what the processor is doing, then no open-source software will make it any more trustworthy. -Complexity Common instruction sets come with hundreds (over a 1000 for x86) instructions. Breaking x86 instruction set https://www.hooktube.com/watch?v=KrksBdWcZgQ Hardware backdoor x86 (not for all processor models) https://www.hooktube.com/watch?v=_eSAF_qT_FY The more complex the system, the more bugs (in hardware and software). Intel had plenty of bugs that were discovered post release, for example the Pentium floating point division: https://en.wikipedia.org/wiki/Pentium_FDIV_bug). Interestingly, the x86 assembly instructions are actually decoded to a sequence of RISC instructions to be used by the internal cores of the CPU. https://stackoverflow.com/questions/5806589/why-does-intel-hide-internal-risc-core-in-their-processors -Security/Backdoors Intel has its Management Engine, which provides full access to CPU, RAM(?), control via network. Advertised for sysadmins, but present on consumer hardware. https://www.hooktube.com/watch?v=3CQUNd3oKBM Intel ME Cleaner - Tool for disabling and pruning Intel ME from BIOS/UEFI firmware. https://github.com/corna/me_cleaner AMD Platform Security Processor (PSP) Similar to Intel ME, based on an ARM core. Video below shows how bios can be analysed. Looks to be somewhat tamer compared to Intel ME, however this may have changed. Dissecting AMD PSP: https://www.hooktube.com/watch?v=IW2YsxSj6zE Speaking to an experienced programmer, he told me the main reason why x86 is the main desktop/PC architecture, is that it allows compiling C almost directly to assembly. This is not the case as for ARM ISAs or RISC V. I guess from a certain perspective, if you had an architecture with enough instructions to better support C (such as array operations) then it might have a chance at competing with x86. ARM Proprietary ISA, several versions available, current is v8. There are licensing fees for use in custom ASICs, don't know how much the documentation covers the internals. The are many Single Board Computers (SBC) using an ARM-based. They are probably a better option compared to an x86 system security wise, however the underlying arch is still unknown. RISC V Reduced Instruction Set Computing V I was once an excited consoomer for RISC V, until I heard about a libre project designing a system-on-chip (SoC) that struggled to get the necessary amendments to the standard (for graphics) put through. Here's a snippet from the project lead: >if you were not associated directly with UC Berkeley, you were basically not welcome. Caveat: if you signed the NDA-like agreement which conflicts directly with, for example, the Debian Charter and the whole purpose of libre licenses, then you got a "voice" and you got access to the closed and secretive RISC-V resources and mailing lists. https://www.crowdsupply.com/libre-risc-v/m-class/updates/nlnet-grants-approved-power-isa-under-consideration This was my "red pill" if you will, that like the development Linux kernel, it's predominantly focused on working towards the interests of corporations as opposed to smaller developer groups. The ISA itself is available to study ( https://riscv.org/specifications/ ) and the main issue technically speaking is that the base instructions aren't long enough to deal with, say a 64 bit address/number directly, thus requiring extensions. The ISA has had quite a few extensions since its inception. Alternatives -POWER ISA originally designed by IBM. Later open-sourced. https://openpowerfoundation.org/?resource_lib=power-isa-version-3-0 One implementation is by Raptor, using Power9 ISA. Comparable to x86 desktops, very expensive. https://www.raptorcs.com/ -Older architectures which have been reverse engineered, or materials eventually released. Such ISAs can be implemented inside a Field Programmable Gate Array (FPGA) for systems designed to give the user more control. Here's a project based on the commodore 65 in an FPGA, project called MEGA65 https://github.com/MEGA65 https://www.hooktube.com/watch?v=KuNB4ocZDXA The points by the chap are pretty good, and one of the main takeaways is: Separate your computing environments. Your most important, trusted code runs on a small, fully verified CPU. While any application that requires high performance or proprietary CPU/system, runs independently without access to the trusted system For example if you were to design a secure phone, the main system could run on a trusted FPGA core (if you trust the FPGA of course), and when service is required, the trusted core controls whether the cellular modem is enabled. Unfortunately, greater integration leads to high chance of security breaches and botnets, so more modular design is necessary for security. -Libre-SoC, a system-on-chip currently in development. Supposedly will be the first open SoC with open source graphics. Graphics seem to be the main issue in preventing fully libre computing hardware. What I mean is dedicated graphics, not software rendering. https://libre-soc.org/ Ultra RISC / OISC? One Instruction Set Computing It may seem crazy, but there are individual CPU instructions that are Turing-complete, and hence an architecture built around this instruction can execute any finite problem (with enough RAM and time). One example is the MOV instruction, which can move data between memory and CPU registers. A C compiler for x86 has been written to compile your code down to just MOV instructions. https://github.com/xoreaxeaxeax/movfuscator The MOV-only on x86 is more of a toy than practical, however there's potential to making a simple processing core in hardware, and by having many of these cores (8+) in a multi-processor system one could achieve better performance. One of the architectures I'm working on is the Subtract and Jump If Less Than Or Equal To Zero (SUBLEQ), as it is also Turing-complete and someone has already written an OS for it here: http://gerigeri.uw.hu/DawnOS/index.html The plan is to make small scale version of the CPU before going for full Dawn OS compliance (256MiB is A LOT of memory for an FPGA dev board XD) That's about as much as I'll say for now, as I would like to spend more time developing. Don't expect it to replace your PC, however as an embedded system it'll have a shot. What do I use? Both my desktop and laptop have Intel processors, one Sandybridge, the other Nehalem. Have not disabled the ME, however planning to give it a test when I have more time. I use Arch and Debian (better compatibility with tools like yosys), but I intend to move Systemd-less system, potentially Gentoo, OpenBSD or FreeBSD. I tried Artix, however I couldn't get some things working, and their wiki isn't nearly as detailed. So if I want to learn about another init system, I may as well start from an OS that comes with it out of the box. What are your options? -Use either intel or AMD, but 'CHECK if there's support for disabling the ME or PSP. ME cleaner even works on fairly recent generations of hardware: https://github.com/corna/me_cleaner/wiki/me_cleaner-status -Use older CPUs. CPU before ME/PSP (or earlier versions where it can be disabled) is probably the easiest. -Use a lightweight OS. Most POSIX compliant OSs can be configured to be lightweight and hence make using older hardware realistic. The most demanding uses are compilation of programs and video playback, so those will be harder to do. -Limit network connectivity on machines that you're concerned about. If it can't call back home then it can't leak your data eh? XD (Hehe, there are other ways for hackers to do it... Air Hopper: https://www.hooktube.com/watch?v=2OzTWiGl1rM) -Aim to use libre hardware, as it gives you more control over hardware. Example: https://github.com/OLIMEX Thanks for reading Anons. (Just to let you know I'm definitely NOT an expert on CPU arch's, I just want a system that's not a botnet XD)

Robowaifu Technician 11/18/2020 (Wed) 05:07:42 No.6858

>>6856 >I had a really good MIPS router called "Linksys WRT160N v3" but a really bad thunderstorm killed it, I miss it. F I hope your implicit prediction that MIPS is dead and gone now turns out to be wrong tbh.

Robowaifu Technician 11/18/2020 (Wed) 05:52:34 No.6861

>>6858 He's probably right. The EOMA68 libre computing project looked into using MIPS but decided against it when they realized how little support it has outside of embedded. >1.2ghz MIPS, with performance being somewhat lacking. The only decent OSes left for it are Debian, but the Libre variants were abandoned years ago due to lack of available MIPS32 hardware. https://www.crowdsupply.com/eoma68/micro-desktop/updates/picking-a-processor Also another option for libre computing that's been picking up steam recently is using FPGAs to run your own custom ISA. It's a very expensive proposition but is currently in development for secure computing; https://www.bunniestudios.com/blog/?p=5971 It's been successfully used for classic console emulation with the MiSTer project. In a few years a 3-400mhz CPU done entirely in an FPGA for under $100 might be a thing.

##+9XbDi 11/25/2020 (Wed) 10:42:46 No.7094

>>7092

Robowaifu Technician 01/26/2021 (Tue) 13:59:03 No.8285

Good news: Chinese companies pushing Android on RiscV to be more independent from USA. This might help the RiscV development and adoption: https://github.com/T-head-Semi/aosp-riscv

Robowaifu Technician 01/26/2021 (Tue) 18:06:29 No.8287

>>8285 I consider Android itself highly dubious, given who develops it. But I can definitely appreciate the development of RISC-V into a sizable alternative ISA hardware platform. Thanks Anon.

Robowaifu Technician 01/27/2021 (Wed) 15:38:27 No.8315

I just found this; https://www.extremetech.com/extreme/319318-robomorphic-computing-robot-response-times Custom configurations may be superior and can be templated and improved upon to create new and better systems for robotics hardware for improved adaptability and faster responses

Robowaifu Technician 01/27/2021 (Wed) 21:20:14 No.8321

>>8315 One of the precepts Carver Mead's, et al, Neuromorphic Computing entails is driving the intelligence of a system further and further out to it's periphery. The closer the response evaluation systems get to the 'borders' of a system, the more biology-like it becomes, and also the more efficient. So, while in the case of robowaifus we can store the significant majority of the computing hardware itself tucked safely away inside a hardened breadbox in the robowaifu's chest, yet logically-speaking it would serve us well I think to follow Carver's lead on this topic. If we can offload much of the sense/response cycle from a 'central' core general-purpose computing system tasked with higher-order decision making and oversight, and onto specialized hardware such as these types of tuned FPGAs, then we could more evenly distribute the computing loads (with an improvement in thermal/electrical efficiency btw). And as the article suggests we'd also improve response times due to latency issues through a whole chain of comms, etc., that would otherwise be required. Also, <"...Improving robot reaction times could allow them to operate effectively in emergency situations where quick responses are required." >that opening image Exactly what kind of 'emergency situations' are they implying here? >SHUT IT DOWN!

Robowaifu Technician 01/27/2021 (Wed) 22:07:26 No.8322

nano/g had a post today re the RISC-V chip being 'verified' by OneSpin about a month ago. >"OneSpin Contributes to the OpenHW Ecosystem to Achieve Processor Integrity for the CORE-V CVE4 Open-Source RISC-V Cores" >"Automated formal solution detects bugs not found by simulation yielding high-quality of results and fast verification signoff: www.design-reuse.com/news/49125/onespin-openhw-core-v-cve4-open-source-risc-v-processor-integrity.html aHR0cDovL25hbm9jaGFucXpheXR3bHlkeWtiZzVueGtneWp4azN6c3JjdHh1b3hkbWJ4NWpiaDJ5ZHlwcmlkLm9uaW9uL2cvNDkwOCNwb3N0MzY0MDgK

Robowaifu Technician 01/27/2021 (Wed) 23:02:52 No.8323

>>8287 >I consider Android itself highly dubious I concur. The worst thing are the proprietary driver. Lot's of hardware just doesn't work on bare linux, but runs on Android. It's almost a joke that we have incredibly beefy SoCs inside our phones, but can barely do much actual work with them.

Robowaifu Technician 01/28/2021 (Thu) 02:12:04 No.8325

>>8321 Yeah, sounds like something we should keep in mind. Object detection based on touch or slipping could be detected in the arms and lower legs. There also are already cam+sbc combos mentioned in the section for computer vision. >>8323 Aren't these drivers from the producers of the hardware? This is not an Android issue. Android can run on open source hardware, for all I know. Android itself is open source, but without the Google apps, and the name. So companies can build their own versions, without Google apps and they need to name it differently. Anyways, my posting wasn't about Android but RISC-V lifting of. There will be more powerful processors coming and there will be better free software libraries to support the RISC-V part of such chips.

Robowaifu Technician 01/28/2021 (Thu) 07:24:23 No.8327

>>8325 Replicant is an example of an alternative Android version funded by the FSF that removes the non-free code and built in Google telemetry. That project made headlines awhile back for finding a backdoor in one of the devices they were attempting to liberate https://www.fsf.org/blogs/community/replicant-developers-find-and-close-samsung-galaxy-backdoor Hardly anyone uses it it because of the few devices that can run it some of the functionality doesn't work unless you install non-free drivers which defeats the purpose. It's a huge issue when it comes to the GPU as it does software based rendering which is very inefficient. Only very recently due to new work being done on the Lima drivers for the Mali GPU may it be reasonable to use on ARM hardware that's almost a decade old. But we're still not there yet. https://redmine.replicant.us/projects/replicant/wiki/DeviceStatus#Replicant-60 Having an open ISA running a permissively licensed OS is fine but when the hardware to use it requires a proprietary and signed bootloader or important parts of the SoC can't run without proprietary firmware that makes it unsuitable for a secure system. That's the road the RISC-V ecosystem is headed down.

Robowaifu Technician 01/28/2021 (Thu) 11:25:01 No.8330

>>8327 > That's the road the RISC-V ecosystem is headed down. This is utterly negative. This was obviously going to happen. However, I think RISC-V itself will improve and there will be more competition. Some companies are more for open drivers than others. In other cases reverse engineering will solve the problem. Then there will be more and more old hardware designs becoming released as open source or the patents run out. And of course some company, university or foundation could create some CPU design and release it as a free hardware design.

Robowaifu Technician 01/28/2021 (Thu) 12:59:46 No.8335

>>8327 Thanks for the info I didn't know about the Replicant platform Anon. >That's the road the RISC-V ecosystem is headed down. I presume you mean a secure system? Or am I misinterpreting your meaning?

Robowaifu Technician 01/28/2021 (Thu) 15:44:11 No.8339

>>8315 After actually reading that article and not just the headline, it turned out to be very interesting. >compute-bound kernels, such as calculating the gradient of rigid body dynamics, take 30 to 90 percent of the available runtime processing power in emerging nonlinear Model Predictive Control (MPC) systems >The researchers report that implementing their proposed structure in an FPGA as opposed to a CPU or GPU reduces latency by 8x to 86x and improves response rates by an overall 1.9x – 2.9x when the FPGA is deployed as a co-processor.

Robowaifu Technician 01/29/2021 (Fri) 03:28:44 No.8341

Yeah, maybe I misunderstood him and he meant it's going well. Here's an interview with somebody working on RISC-V: https://youtu.be/lXdx0X2WHfY

Robowaifu Technician 01/29/2021 (Fri) 07:23:00 No.8346

>>8341 One of the most important things about non-proprietary standardization is longevity. For example, regardless of whatever else may happen in the software development industry's space, in 50 years C++ will still be a real thing, and you will still be able to compile your code then. This is simply b/c it's an open (and in this case international) standard. This is one important reason I stress C & C++ here, because they will stay around for us over the long haul. RISC-V seems to bring this same kind of benefit to the table for processor hardware, as this guy brings out in the interview. Thanks Anon, interesting. Please drop more here if you think of any on-topics.

Robowaifu Technician 01/29/2021 (Fri) 09:47:38 No.8349

FreeBSD on RISC-V talk https://linuxreviews.org/FreeBSD_Fridays:_Introduction_to_RISC-V_on_FreeBSD

Robowaifu Technician 02/05/2021 (Fri) 07:31:01 No.8453

>>6467 The reason why relatively affordable and owner controlled POWER10 hardware won't be available has to do with the new OMI standard not PCIe 5 >In the future, even your RAM will have firmware; and the subject of POWER10 blobs https://www.devever.net/~hl/omi As that page explains this is very a different situation than with the controller boards on hard drives or SSDs having locked down proprietary firmware. Saw this coming down the pipe for awhile(and has already been an issue with DDR4 on some SoC as mentioned in the footnotes in the link above) but I thought it would be a major issue in specialized NVMe drives for gaming or other niche tasks first. The only realistic solution for a FLOSS OS in a world where RAM is locked down is to have the entire OS only run in the cache on the CPU. Which isn't as crazy as it sounds considering how quickly it's growing. https://www.nextplatform.com/2020/01/16/cache-is-king/ These issues always surface in high performance computing environments as they are the first to adopt new standards so by the middle of this decade it might be a more pressing issue that gets more attention. Heck I remember first reading about x86-64 CPUs that had blown fuses to only work with specific motherboards from servethehome.com https://www.servethehome.com/amd-psb-vendor-locks-epyc-cpus-for-enhanced-security-at-a-cost/2/

Robowaifu Technician 02/16/2021 (Tue) 22:36:21 No.8580

An anon over in the R&D thread made a post >>8548 that led me indirectly to this. https://web.archive.org/web/20180205224807/https://spectrum.ieee.org/tech-talk/computing/hardware/lowbudget-chip-design-how-hard-is-it

Robowaifu Technician 03/27/2021 (Sat) 22:59:45 No.9234

>"We are now using white designed but East Asian built cpus, because corporate cancer has devoured our fabs, and are likely to soon be using Chinese designed CPUs. People are starting to use the Exynos SoC, which is a Samsung design built in a Samsung fab for a Samsung built and designed CPU, and the Media Tec chips, which are designed and built in Taiwan. If I was building a home security system today, it would be running on Taiwanese designed and built CPUs and SoCs. Don't know what this guy's blog is all about yet, but this quote most definitely caught my eye insofar as our computing concerns here on /robowaifu/ go. https://blog.reaction.la/war/where-we-go-from-here/

Robowaifu Technician 03/27/2021 (Sat) 23:36:53 No.9236

We are definitely going to need some kind of Robowaifu Security General, etc. But until we do, this thread probably is a better place than most to simply dump (at least somewhat) pertinent information, I suppose. Like many other domains we need to focus on, this one is most definitely multi-variate and ~~impossible~~ tough to pin down to a single topic. https://en.wikipedia.org/wiki/Schnorr_signature https://medium.com/bitbees/what-the-heck-is-schnorr-52ef5dba289f https://medium.com/digitalassetresearch/schnorr-signatures-the-inevitability-of-privacy-in-bitcoin-b2f45a1f7287

Robowaifu Technician 03/27/2021 (Sat) 23:45:18 No.9237

>>9236 https://en.wikipedia.org/wiki/Lightning_Network

Robowaifu Technician 03/28/2021 (Sun) 00:30:11 No.9238

>>9237 https://medium.com/dataseries/triple-entry-accounting-system-a-revolution-with-blockchain-768f4d8cabd8

Robowaifu Technician 03/28/2021 (Sun) 01:03:20 No.9239

>>9238 https://academy.binance.com/en/articles/blockchain-scalability-sidechains-and-payment-channels

Robowaifu Technician 06/14/2021 (Mon) 19:31:21 No.10930

>>6629 >Intel killed that company just as AMD is going to kill Xilinx and Nvidia will destroy Mellanox. smh At least I hope Lattice will remain, the open-source tool chain is great to have (project IceStorm).

Robowaifu Technician 06/14/2021 (Mon) 20:37:35 No.10934

>>10930 >At least I hope Lattice will remain, the open-source tool chain is great to have (project IceStorm). Sounds interesting Anon. Can you share more about it here?

Robowaifu Technician 06/14/2021 (Mon) 21:54:15 No.10936

>>10934 >Sounds interesting Anon. Can you share more about it here? For as long as FPGAs (Field Programmable Gate Arrays) existed, the vendor software used to convert the Hardware Description Language (HDL) like Verilog/VHDL to logic netlist, place-and-route, and bitstream generation has been proprietary (Xilinx Vivado, Altera Quartus etc.). This meant that any open designs could only be open at the HDL level, and the rest had to be generated by the user. Even the top-level HDL files were sometimes proprietary as they were generated by vendor tools. This changed when some very clever people reverse-engineered Lattice's iCE40 FPGAs. From there, open-source tools were written to support netlist generation, place-and-route, and bitstream generation. These tools are not only open, they run faster and can be used on an embedded computer (such as Olimex or Banana Pi). The latter point was considered unspeakable (vendor tools typically take +5GB of space and the RAM usage would be fairly high). This projects kicked off further development and research into other FPGAs. Of all the things I've heard in open-source, this is probably the most impressive. At the moment the Yosys project (umbrella group) supports several FPGA architectures (ordered highest to lowest in terms of number of resources and capability): -Xilinx 7 series -Lattice ECP5 series -Lattice iCE40 series See the docs for more info: https://symbiflow.readthedocs.io/en/latest/toolchain-desc/yosys.html What does this mean for us? Well, we can instantiate any processor architecture (MIPS, Z80, 6502, etc.) and design customised digital processing block or peripherals. Perhaps you need a 50-channel motor control module directly hooked up to a CPU running at 100MHz? No problem! With these tools timing analysis can also be done, resource utilisation checked etc. If you want to get started, TinyFPGA series of boards are not a bad choice. I have the BX model, and using it was straightforward on Debian Linux. (Also supports other OSs as well of course).

Robowaifu Technician 06/14/2021 (Mon) 23:36:42 No.10938

>>10936 Wow, that's much more interesting than I expected. Thanks for taking the time to spell out the details for us. >Perhaps you need a 50-channel motor control module directly hooked up to a CPU running at 100MHz? No problem! More like 500 channels, so maybe we need a wee little cluster of these CPUs? :^)

Robowaifu Technician 06/15/2021 (Tue) 07:22:24 No.10941

>>10938 >Thanks for taking the time to spell out the details for us. There's something fun about turning history into a tale like that. Probably sticks in your head better too :P >More like 500 channels, so maybe we need a wee little cluster of these CPUs? :^) Now you're just being greedy XD Although the EC5 and Xilinx 7 series might actually be able to handle that many (you'll be limited by the IC package more than anything...)

Robowaifu Technician 06/15/2021 (Tue) 08:01:23 No.10942

>>10941 >history into a tale You know, I've thought that we should find someone who's interested in documenting the rise of the robowaifu age at the hand of a small band of anonymous men on the Internet. Should be a good read if done well. >Now you're just being greedy XD Heh, maybe. :^) >Head, incl. eyes, lids, brows, mouth, jaw, tongue, nostrils, throat (w/ potentially cooling water consumption controls/valving) >50+ channels >Neck+shoulders+chest, incl. head rotation/leaning, 'breathing', arm-rotation controls, shoulder girdle, ~50 channels (2 arms) >Arm, incl. add'l shoulder, elbows, wrists, fingers, thumb, all finger knuckles, palm (50 channels per arm) >Central torso/Pelvis, incl. spinal column rotation/leaning, pelvic girdle control, hips w/ rotations, ~50 channels >Leg, incl. add'l hip, knee, ankle, ball of foot, toe flexion, ~50 channels (2 legs) >Various power charging/control systems ? >Various cooling systems ? >Various computing power control/conditioning systems ? >Add'l various kinematic/positional systems ? >Visual analysis systems ? >Hearing analysis systems ? >Speech control systems ? >Communications & control systems ? and last, but certainly not least >Literally hundreds of sensors of varied types, spread over the whole body (haptics, thermal, electrical, RF, pressure, kinematic) It's quite possible that in the end, 500 is an underestimate! :^) > (you'll be limited by the IC package more than anything...) Yes, agreed. I've already gotten some design approaches that encompass hundreds of connectors in a compact volume, pretty much lifted directly from industrial controls approaches.

Robowaifu Technician 06/15/2021 (Tue) 13:00:45 No.10944

>>10942 I was thinking of a distributed topology, where across the whole body there are low-level controllers that deal with sensors/actuators on an individual level, while communicating with a central (beefy) processor that's running the main OS. Something like a CAN bus in cars (although I can't speak for CAN as I haven't used it yet). In that case, you won't need 100s of outputs on a single FPGA, but perhaps limited to about a 100 at most. Of course the difficulting of micro-managing movement arises. But surely as the brain doesn't fully manage our bodies (the spine and other parts help out), so should the robo-waifu main system should delegate tasks? Imagine a command protocol where instead of telling the leg to move to a specific set of coordinates, the main computer provides required tolerances (i.e. "appendage within 20 cm radius of torso" or "leg must distribute 35% of the overall weight" etc.) and the leg controller (MCU or FPGA etc.) actually does the system analysis to get the leg there. With greater tolerances, the solution can be achieved faster, and so rapid motions are either less precise, or preparation is required beforehand (the robowaifu gets into a running position and the actual run is a simple progression)

Robowaifu Technician 06/15/2021 (Tue) 13:11:51 No.10945

>>10942 >>10944 Also just had a thought. The local appendage controllers can be provided with a time duration for specific tolerances, thus allowing some level of autonomy. The main controller would only update on a variable basis (depending on the complexity of the action) and only respond in real-time when an interrupt is received from the local controller saying that the appendage is outside the given tolerances. Perhaps like TCP (when a packet drops), the frequency at which main controller sends commands sharply increases when the appendage is outside tolerable range, and decreases proportionally to the rate of change of the deviation from tolerances.

Robowaifu Technician 06/15/2021 (Tue) 16:07:52 No.10946

>>10944 >>10945 (Another anon) Yeah, that sounds more like what I want, though others here want a central bread box in the chest with everything inside.

Robowaifu Technician 06/15/2021 (Tue) 19:05:52 No.10947

>>10944 >>10945 Yes. I've thought long and hard about these kinds of issues myself. Honestly, I think we probably need a new thread here that targets these kinds of topics. Something like "Robowaifu Motion Control Systems", or "Robowaifu Distributed Control Network" or something like that. Ideas?

Robowaifu Technician 06/22/2021 (Tue) 18:09:16 No.11011

>>10947 >Ideas? Hehehe, yes :) Currently writing it, 1114 words so far. I'll try to make a basic diagram too. I'll create a new thread for it; does "Robowaifu System Overview" sound alright?

Robowaifu Technician 06/22/2021 (Tue) 18:18:07 No.11012

>>11011 Sure. I'd say that sounds good, but you might want to tuck a 'control' in there somewhere in the subject. Seems to be a central idea on the topic. I'm sure your writing will guide you to a good name Anon.

Robowaifu Technician 06/25/2021 (Fri) 21:39:55 No.11098

>>10944 I've actually had this kind of idea rattling around in my head for a while and never bothered committing it to text. I think what is the most likely feasible way to orchestrate a robowaifu "brain", for lack of a workable AGI, is to have specialized 'skill' AIs that handle specific tasks, rather than breaking it down by hardware subsystems. For example, a 'locomotion' skill would need to incorporate both the legs and arms in order to keep balance and also provide a natural-seeming stride. Your 'chatbot' AI could be kept insulated from all the other skills so it only has to keep track of information relevant to its skill, rather than everything needing models for everything. This also serves to help break up AI development into a task manageable by a collection of random anons. It also means individual skill data can be crowd-sourced, so in theory all the AIs would learn from each-other. Group learning probably only really makes sense for 'non-personality' AIs, tasks that objectively have a way to be performed well (walking, driving) rather than subjective tasks (speech, decision-making, artistic-type tasks). These specialized skills would somehow need to co-operate. Perhaps something like treating hardware parts as a 'lockable' resource so two skills don't try to use the legs and once and end up with your robot falling over. It'd make doing something like grabbing something fluidly as they walk by a nightmare and probably force them to do something like "go to position in front of object" > "stop" > "grab" > "proceed to next position" but it's better than the alternative. We'd then have to train some sort of 'taskmaster' AI to handle behavior, taking inputs and outputs from these discrete 'skill' AIs and making behavior decisions based on them. I think that's a more manageable task that having one mega-AI that does everything, especially considering that hypothetical mega-AI would have to make the same decisions. This has kind of been a ramble, but I'm interested to see what everyone else thinks about this idea of 'consciousness architecture'

Electronic Chronicler 06/25/2021 (Fri) 22:00:38 No.11099

>>11098 Good ideas Anon. The program separation as you mentioned is a goal we should strive for (at least at this point). Have a look at the thread I made on RPCS (>>11018) as you may find it more relevant for the what you've mentioned. I'll be expanding what I wrote into a doc, and software architecture will be included (at least enough for the programmers to get going). >'consciousness architecture' This morning I was thinking about how the robowaifu software platform might work. As the base, only the lowest level functions will be present (sensor check, calibration etc.). From there, you (the user) can load 'modules' that provide functionality and make the robowaifu's behaviour increasingly complex. Even better if we could come up with an API that could be a long term standard, so that you could compare 'alpha' stage chatbot robowaifu all the way through to the latest and greatest masterchef/scuba-diving/prankster of a waifu.

Robowaifu Technician 06/25/2021 (Fri) 22:33:25 No.11100

>>11099 Yeah, that thread does seem more relevant. It might be more valuable to move this discussion there for later reference, since it seems to fall under the umbrella of 'control systems'

Robowaifu Technician 06/26/2021 (Sat) 04:18:42 No.11112

>>11098 I don't know what you mean by a workable AI. You seem to have this ideal of some completely from the scratch self learning system which you call AI. That aside, your thoughts are quite similar to mine. Same goes for >>11099. Though, I don't really see any problems with it. We should have subsystems, running on different hardware and communicate with each other. Of course, the software for it could be shared with others, since it doesn't contain private information.

Robowaifu Technician 06/26/2021 (Sat) 19:57:06 No.11127

>>11112 I meant workable "AGI" or "Artificial General Intelligence", which is different than the types of AI we have today. It could also be termed "strong AI", and has the ability to learn, on its own, any task a human can. At present, what we have is "weak AI", which is generally an AI that is trained on and capable of performing one specific task (For example, image classification, driving, generating text, etc.). As a 'strong AI' is likely decades out (if not further, outside of any of our natural lifetimes), my idea is to combine multiple "weak AIs" into a whole, with a 'supervisor' AI that is tasked with figuring out the right response to a situation. It would still be unable to learn a new skill on its own and would require human aid to do so. However I believe it would, with enough single-task AIs, be able to be interacted with in a convincing enough manner for you to forget that fact. This approach's most difficult part is still at the top, as a machine learning program to figure out the right thing to do still straddles the line between "weak" an d "strong" AI, but it has the benefits of some of the work already being done, being compartmentalized enough to be divided into sub-tasks, and also means we don't have to solve the harder problem of making software that can learn an entirely new skill.

Robowaifu Technician 06/30/2021 (Wed) 22:12:45 No.11170

>>11127 If it's like a human then it's AGI. Doesn't matter how it's designed inside. It should be made of different parts, including regular programs. Which also debunks the problem of some rampant super AGI, especially out of the blue.

Robowaifu Technician 07/02/2021 (Fri) 21:37:11 No.11195

Even though the primary topic for this post is about a secure OS implementation, I'm going to drop it ITT since it also relates to RISC-V hardware. https://microkerneldude.wordpress.com/2021/05/05/sel4-on-risc-v-verified-to-binary-code/ https://sel4.systems/

Robowaifu Technician 08/14/2021 (Sat) 12:51:43 No.12421

A mad lad made a 1000 transistor silicon chip in his garage. https://www.youtube.com/watch?v=IS5ycm7VfXg >My chip is a simple 10×10 array of transistors to test, characterize, and tweak the process but this is a huge step closer to more advanced DIY computer chips. The Intel 4004 has 2,200 transistors and I’ve now made 1,200 on the same piece of silicon. http://sam.zeloof.xyz/second-ic/

Robowaifu Technician 08/14/2021 (Sat) 17:20:54 No.12427

>>12421 This is really cool, thank you very much Anon! :^) >related http://sam.zeloof.xyz/maskless-photolithography/ http://sam.zeloof.xyz/developing-patterning-process-for-homemade-microelectronics/ http://sam.zeloof.xyz/category/semiconductor/ He clearly knows what he's doing, but he's using quite primitive techniques relatively-speaking. Obviously that's a prerequisite under these circumstances, but it's getting the job done after all. Seems like he's having some process contamination issues going (unsurprisingly tbh). But the size of the fab final assembly should mean he can fit it all into a homemade clean containment glovebox, so there's that. My instinct is that you should be able to get this to a MC68000-tier machine process w/o any significant changes to the photolithography mechanism designs, apart from the steppers.

Robowaifu Technician 09/15/2021 (Wed) 07:24:14 No.13155

I haven't really thought much about security other than simply not giving it any sort of internet connectivity. I had thought about giving it some wireless connectivity, but only because of the limitations of fitting a PC inside of a space roughly the size and shape of a human skull and torso. I was thinking of a completely offline server with wireless transceiver and another transceiver inside the skull, with a signal only strong enough to maintain a signal within my own property.

Robowaifu Technician 10/21/2021 (Thu) 06:50:59 No.13757

>>4506 Going to necro this thread. Does anyone use a librebooted thinkpad for their development? How is it? I'm getting one for backdoor-less work. Second pic unrelated.

Robowaifu Technician 12/22/2021 (Wed) 12:04:49 No.14745

>>6858 MIPS back on the menu? Restructure in 2021. https://www.mips.com/about/

Robowaifu Technician 12/23/2021 (Thu) 07:48:12 No.14764

>>14745 https://www.eejournal.com/article/wait-what-mips-becomes-risc-v/ I can't seem to find an official announcement but the article is linked by RISC-V's website: https://riscv.org/news/2021/03/wait-what-mips-becomes-risc-v-classic-cpu-company-exits-bankruptcy-throws-in-the-towel-jim-turley-electronics-engineering-journal/

Chobitsu Board owner 01/19/2022 (Wed) 21:21:11 No.15031

>>13155 Please contribute ideas into the Sumomo Project thread Anon (>>14409) We're designing solutions that are intended to deal directly with issues such as this. Your feedback there would be appreciated! >>13757 >Going to necro this thread. Lol, we don't have such a thing as necro'ing here on /robowaifu/, Anon. We keep subjects on-topic to the extent feasible. Your's is in the right place afaict. I wish I had info for you, but I've never gotten my own Thinkpad yet. I know it's a popular topic though, so I imagine it's locatable info. Please share here again with anything you uncover Anon! >>14745 >>14764 This would be welcome if true Anon. Have any >tl;dr for us a month passed?

Report/Delete/Moderation Forms

Delete

Password Delete only files (Removes the file reference to the posts) Delete media (Removes the saved files from the server)

Report

Reason Global