SoylentNews

So I was writing a post in the comment section of this story. It got me thinking about a few bat-shit crazy ideas I've had rolling around in my head and how they would be perfect fit for a modern desktop/laptop RISC-V SoC. Keep in mind these are what I consider pipe-dream paper napkin ideas that I would like to share with others to see what they think. This is my first journal entry as well. Any references to RIO or RapidIO is from ideas from my original post I'll probably paste as a comment here later on. It might be a little messy and chopped up but I'm pressed for time. I've probably skipped a few things or left some stuff out. I just want some opinions and feedback if any.

* RISC-V APU. Something like an IBM Cell or larabee with a few general purpose RISC-V cores and tens of grouped, modular lightweight risc-v cores. The system can be built as a heterogeneous setup so data loaded into RAM by a user program is directly addressable by the micro cores without copying from main memory. Would be even better if we write GPGPU code the same way we write CPU code. Since the instructions are the same, a single compiler builds all of the code in one go. Code for the micro cores is restricted to certain instructions or has access to special instruction for texture, video decode or whatever else is needed. A preprocessor keyword can tag code sections that are to be ran on the micro cores so the compiler knows what to do with it. GPU instructions and associated data can be tagged so it is loaded into HBM and not slower main memory.

Perhaps the HBM is some kind of massive L3 or L4 hybrid cache that is part system memory and part cache. Maybe it works similar to Arm's tightly coupled memory where the CPU bypasses cache for the HMB and GPU instruction reducing latency by eliminating cache searches. Now you have a system that reduces GPGPU programming complexity by using the same CPU instructions and design. In a way, this removes the need for a GPU driver as the GPU is just a bunch of CPU's. No video driver means easier development of graphics libraries and API's. No longer bound to OpenGL/Vulkan/DirectX because that's what the GPU maker supports in their proprietary driver. The code could also be statically linked or compiled right into the application binary meaning the application can contain the entire 2D/3D rendering stack.

I also think this is a great system for co-processing of all sorts of other things such as 3D sound, physics, simulation, etc. The idea is to eliminate externally programmed coprocessors or accelerators which require drivers. Though it remains to be seen if this approach is practical hardware wise as both cell and larrabee failed. But I think the design might be useful for high performance computing outside of Graphics or an excellent companion to a pure GPU. For example, standard cores handle game loop/logic/input, the micro cores run AI and physics, and the GPU renders video. I would also think that the host OS would directly handle scheduling thus making them fully managed cores. You can set affinity, execution caps, loading, see which threads or processes are running on them, memory used etc. Though, it remains to be seen if this is any less complex coding wise vs current GPGPU/Shader programming.

* Two-way trust security processor. this is one I've been pondering for a while but I'm not sure how practical or secure it can be. Big companies like making money off of their IP. They don't like open platforms with CPU's that can't hide their precious unencrypted bits. We don't like platforms containing secret code running on secret CPU's doing secret things which includes full hardware access outside of the OS kernel. So how about we come to a compromise and build a system both parties can trust?

It would work like this: Limited secure VM's created by a processor extension allowing black box modules to run inside the black box VM out of system view. The VM and associated memories and I/O paths are completely isolated from the system, including the host kernel. The key part here is the user maintains full control over what the VM can access through control flags set before the VM is spun up. It's like when you install mobile apps and it lists what permissions the app needs. A shared memory segment can be used as a FIFO or DPRAM to allow the VM to communicate with the host OS using mmap() and the like. An SPI or i2c port can then be dedicated to a user added commercial security chip that is trusted by the IP holders which contains keys or another crypto CPU that does verification but has zero access to the systems hardware, it's just a secure peripheral. Everything is controlled by the initiation application including memory needed, cpu core affinity and execution cap. If a program wants to run secure code, a special OS flag would trigger a prompt to ask the computer owner's permission to start the VM AND what memories and I/O devices it needs to commandeer or share (cpu, memory, sound, video, framebuffer, GPU). If the initiator application is terminated, it's secure VM is also terminated. Another mechanism is a memory scrubber in the IOMMU which zeros out memory once the VM is killed before returning it to the host OS.

I should also note that these secure VM's are not like a regular VM in the sense that they are limited to a certain number of resources. For example the secure VM's should run entirely from memory and have zero access to certain hardware like disk controllers, bus controllers, and certain IO hardware like USB or input devices. Though, certain output devices can be securely mapped like audio and even secure frame buffers or segments of a frame buffer. The idea is if you want to securely process data, go ahead. Just be aware you can only do it in a limited yet secure environment. The user can't see the inside of the VM and the VM can't see outside of it's designated secure paths save for just the shared memory segment and perhaps two way interrupt lines. And of course, all black box secure VM's and associated resources are fully visible and auditable by the user from the outside. The user also has the ability to kill any of those VM's at *any* time.

My only problem is I don't know how to deliver the secure code to the VM or how it gets decrypted and ran without the user being able to extract keys or hacking a decrypted module to run in a simulator or unsecure VM (though I'm sure this is already a problem). Perhaps some boot-strap process between the secure VM and external security processor which verifies the VM and then lets the initiator application know it's safe to copy the encrypted binary blob to the VM via shared memory. Then the code is decrypted in VM and ran.

The user can also create their own secure VM's. So it's a secure computing system for everyone including the owner. This could useful for creating isolated VM's for secure computing, banking, communications, web servers, etc. I also see it being used for secure soft-dongles enabling commercial software to run by stuffing certain critical components into the secure VM and using shared memory to operate. To me it's a fair way to do this and the extra work to build the secure VM is worth it. Can this system be abused? Of course. But I think the key part of the idea is the user/owner is in full control of the VM's from the outside. Even if my idea is dumb and won't work the two-way idea is the key point and might be practical in some other form. It sounds nuts but I want to be able to watch Netflix on my Linux powered Risc-V system without secret software running on secret CPU's while SMI's run unchecked all the while having FULL access to every bit of hardware in the system including main memory. No thank you.

* Infinite framebuffers and displays. The idea is this: a display is just a bitmap that is updated constantly to produce a moving picture. Why should framebuffers be fixed in size and number? The systems IOMMU can be linked to the graphics system to create a dynamic display system. Let's say we have our pipe dream Risc-V SoC in a mini case with 8 mini RapidIO ports (USB3/Thunderbolt replacement) and we have 8 RIO monitors (or active RIO->HDMI/DP/DVI/VGA dongles).

As you plug in each monitor, the RIO switch/controller interrupts the host OS and the RIO management system sees that a new device is plugged in. The RIO manager queries the device and sees that it's of type monitor and passes that info to a display manager. The display manager queries the monitor and finds the modes it can handle. The display manager sees that it's a 1920x1200 monitor and then tells the user a new display is ready and the user decides what to do with it. Once the user figures out what they want (a 1920x1200x32 60Hz workspace), the display manager tells the kernel it wants a new framebuffer and the kernel then tells the IOMMU to create a ~10MB frame buffer and map it to the GPU. The display manager then presents this to the display server and the display server creates the workspace and writes it to that framebuffer.

These framebuffers are also written to by the GPU meaning all accelerated 2d/3d graphics are also written to any frame buffer the user program specifies. This decouples the display from the rendering allowing for more flexibility. This same system can also create virtual framebuffers that can be mapped into I/O space and read by other hardware devices or read into software like the Linux virtual framebuffer. Perhaps multiple displays could be mapped to one buffer and a video wall can easily be created without the OS or it's components knowing how. Stream 3D rendered video directly over the internet via a compressed video stream? No problem!

Another idea is this framebuffer system can tie into the whole two-way trust VM by allowing overlapping frame buffers so secure video can be overlaid on top of the users desktop. The idea is a special hardware component would know the coordinate mapping between the two and as the data is copied to the actual display, the hardware would flip between the two buffers keeping them separate at all times. As the user moves the video display window, the host OS updates those coordinate positions and the hardware does the rest securely. This prevents the user from attempting to read the framebuffer back into the system to record the video. A bit like how the old PC TV tuners which fed video directly to the video card and a magenta chroma key was used to tell the GPU where to map the video in the framebuffer. Another method would be to create a write only port to a secure frame buffer that behaves like a DPRAM with a mask. As the desktop display system writes the data to the buffer, it gets copied until it hits the mask which represents the secure video window which is simply not written to. If the display is full screen, a flag would simply tell the OS to not bother writing to that framebuffer saving bandwidth. Of course, any outside paths would have to be secure so more secure hardware must be added to the system. But as I stated earlier, this can also be beneficial to the user since the user has the same exact access to the security facilities.

All of this requires a crazy IOMMU and memory system. And most likely impractical in terms of die size. Some of this may also decrease throughput as a result of increased memory operations. Fun to think about though.

House passes 20-week abortion ban

The measure passed heavily along party lines, 237-189.

The bill allows exceptions in cases of rape, incest or to save the life of the woman and wouldn't penalize women for seeking to get abortions after 20 weeks.

The legislation is likely to face a tough sell in the Senate. A similar bill passed the House in 2015 but was blocked by Senate Democrats.

With only a 52-seat majority it would be unlikely Senate Republicans could gather the 60 votes needed to move the legislation to President Trump's desk.

The House just passed a 20-week abortion ban. Opponents say it's “basically relying on junk science.”

Semen-contaminated flutes might have been given to children, California school officials warn (archive)

Several school districts in Southern California warned parents this weekend that flutes and recorders given to children through a nonprofit music program may have been contaminated with bodily fluids. At least one district specified that those fluids could have been semen.

Local, state and federal agencies were investigating a male music teacher who visited schools in Southern California through a program called Flutes Across the World, according to updates from the Saugus Union School District, which serves the Santa Clarita area.

“The performer distributes a flutelike musical instrument made of PVC pipe or bamboo to students during a music lesson, and the allegation is that he contaminated some of these instruments with semen,” Saugus Union Superintendent Joan Lucid said in an email to parents on Saturday. “These allegations are deeply concerning, and I realize they raise many questions.”

The California Department of Justice and the U.S. Postal Service were among the agencies investigating the program, the district said. Lucid said children were never alone with the music specialist, who was not a district employee.

School officials allege flutes used in children’s music program may have been contaminated with semen

Flutes "stained with a man's bodily fluids" issued to California schoolchildren

Flutes Across the World: Japan Edition.

'Evie' now lives in fear in Jakarta slum - Obama's nanny

For Some Chinese Uighurs, Modeling Is A Path To Success

Previously:

China Bans Islam-Related Names in Xinjiang
Massive DNA Collection Campaign in Xinjiang, China

Chuwi Announces The LapBook Air: For Preorder Now

Don't sue!

Here we are, two days after The Morgatory Blizzander took exception to one of my submissions that was approved by another ed. Strange, because TMB is not even an ed, he is only a coder, from what I understand, so how could his objection overrule the decision of an editor? The result, as documented in my last journal, is that my submission has been deep sixed, marked as hidden, so that it is not in the queue, not in the pre-queue, not anywhere! I request, respectfully, that the eds cease this act of censorship. TMB's objections are no more valid than mine, and since I thought this particular article important enough to be a submission to SoylentNews, TMB's objections are noted, but now I think he may actually be a Nazi. Which, as a Native American, seems strange. But I do remember a scene in the movie "Under the Volcano", starring Albert Finney, where a Metis riding on a bus, and wearing a National Socialist Party Pin, harasses a full-blood Native American Mexican. And then it hit me! Not about racial purity at all, since the half-breeds could feel superior to the full bloods, as long as they were not of the "right" blood. TMB is a mongrel. Not that there is anything wrong with that, I am one, too! But to object to an investigative piece looking into the alt-right, because he is afraid, and I repeat, AFRAID, that I am calling him a Nazi? Methinks the Buzzard protests too much. Let my submission go, eds! Let it go.

Trump Says He Groped Melania in Public, Ivanka Looks Down on Him, in Newly Released Recordings

Donald Trump - The Howard Stern Interviews 1993-2015

Every Soylentil should, on occasion, pull back the curtain and see how sausage is made. Being the site this is, all the discussions by the editors are logged on IRC, and often it is very interesting what is said there:

[12:16:20] cmn32480: Could you please take a look at this story? TMB has some strong views we should not run it (see scroolback): https://soylentnews.org
[12:16:21] ^ �03Error�
[12:16:24] afk
[12:19:02] came from aris5tarcfhus..; wee probably shouldn't run it
[12:19:26] Bytram, that a couple white supremacists exist in the US is not news. running a story about it is not dissimenating news, it is furthering the nazi boogeyman myth and painting tens of millions on the alt-right as literal nazis when there are less than a hundred thousand white supremacists of any variety in the US.
[12:20:20] it serves no purpose but that of propaganda
[12:20:42] am puitting in my standing desk... will tak e apeek at it when I get a moment
[12:23:20] and it's not a speech issue. dingleberry is free to post it verbatim in his journal. it does not meet any criteria as a news story though.
[12:43:35] -!- TheMightyBuzzard has quit [Ping timeout: 276 seconds]
[12:46:01] Beware.... There are CLI programs (if somewhat arcane, can maintain many hundreds of systems) and also in GUI (easy to use, somewhat harder to leverage against hundreds of systems). Some of these have malware. Here's an example of one area where we found some.
[12:46:09] replace CLI/GUI with right/left
[12:46:25] I stand by my decisoion.
[12:46:39] NCommander: ^^ would you please take a look at this and weigh in if you would.
[12:46:46] -!- TheMightyBuzzard [TheMightyBuzzard!~TheMighty@Soylent/Staff/Developer/TMB] has joined #editorial
[12:46:51] I would love to stay and chat but I need to be AT work in about 10 minutes.
[12:46:59] blerg. my local nameserver took a shit.
[12:50:26] fuckin hell. it's my damned internet connection not my nameserver.
[12:53:15] Bytram, that MIGHT be valid if framed that way. leaving dingleberry's commentary makes certain it is framed otherwise.
[12:56:15] Looking
[12:56:55] Ugh
[12:56:59] * NCommander is on the fence
[12:59:11] TheMightyBuzzard, I get where you're coming on the boogeyman argument. The summary as it stands kinda sucks but the actual NYT article has a couple of interesting insights on it about the size and measure of the alt-right and relationship to hate groups.
[12:59:48] Possibly scrap the current summary, make it clear it's an op-ed piece, and that it's by definition opinion with a look inside these groups, and stick a disclaimer on it for good measure.
[13:00:52] the summary as it sits is complete crap and propaganda
[13:02:00] NCommander, have you ever hung with alt-right folks? the only relationship happening there is the extremely small hate groups agree on some issues while the vast majority are happy to denounce them if given half a chance.
[13:03:02] the biggest issue I see is the use of Alt-Right being easily transposed with Nazi
[13:03:10] that is in the NYT piece as well.
[13:03:19] ya, that's by design.
[13:03:53] i think the piece both the NYT Opinion piece and the story sub are hard left leaning propaganda and should get dumped.
[13:04:41] it isn't worth trying to make it an even reasonably even handed rewrite as the source is so far one way that theere is no center
[13:06:56] it's not even really the story that bugs me. the site could and has survive a bad story.
[13:07:51] it's that some of the folks in charge of picking what's worth reading genuinely thought this was. that disturbs me greatly.
[13:08:57] I've set the story for no display pending continued arguement
[13:12:26] emphasizing what cmn32480 said, in the first two paragraphs "extreme right" "alt-right" and "neo-Nazis" are used interchangeably. that is pretty solidly propagandizing.
[13:15:52] Hrm
[13:18:27] FYI: the internal definition of alt-right is something along the lines of "conservative, likely but not necessarily nationalist who sees the Republican party as not representing him/her anymore"

As I said, interesting. I have learned that TMB probably has actually hung out with alt-right types, and the we probably should not be running submissions by aristarchus. Moar Free Speech, Y'all!

I think I may have figured out at last what is making the Human Race so unhappy, and it's not just to do with chasing after little green pieces of paper. It occurred to me recently, but I'm getting rather forgetful these days. Let me see if I can remember.