SoylentNews is people
SoylentNews
Weinstein Accused of Rape
Harvey Weinstein Accused of Rape in New Yorker Exposé
From Aggressive Overtures to Sexual Assault: Harvey Weinstein’s Accusers Tell Their Stories
Gwyneth Paltrow, Angelina Jolie and Others Say Weinstein Harassed Them
Harvey Weinstein Paid Off Sexual Harassment Accusers for Decades
Harvey Weinstein gives first interview after shocking sex harassment claims
Did somebody say Paltrow?
Las Vegas Shooter: Stone Cold Vampyr
Calm Before the Storm
What Did President Trump Mean by ‘Calm Before the Storm’?
President Trump was clearly looking to make some kind of news, but about what, exactly, was not clear. And the mystery, as it often does with a president whose statements baffle even his staff, only deepened the next day.
On Thursday evening, the White House told the presidential press corps that Mr. Trump was done with his public schedule for the day. But around 7 p.m., Mr. Trump summoned reporters who were still at work to the State Dining Room, where he was throwing a dinner for military commanders and their spouses.
Gesturing to his guests, he said, “You guys know what this represents? Maybe it’s the calm before the storm.”
“What’s the storm?” asked one reporter.
“Could be the calm before the storm,” Mr. Trump repeated, stretching out the phrase, a sly smile playing across his face.
“From Iran?” ventured another reporter. “On ISIS? On what?”
“What storm, Mr. President?” asked a third journalist, a hint of impatience creeping into her voice.
As the generals shifted from foot to foot, Mr. Trump brought the game of 20 Questions to an end. He praised his beribboned guests as the “world’s great military people” and excused the stymied reporters, who returned to their workstations to start another round of: What was the president talking about?
By Friday, the White House was still unable to shed light on the matter; several of Mr. Trump’s aides said they had no idea what the president meant. But the press secretary, Sarah Huckabee Sanders, wanted to make one thing clear: Mr. Trump wasn’t just teasing his favorite antagonists. He was sending a message.
“I wouldn’t say that he’s messing with the press,” Ms. Sanders told reporters. “I think we have some serious world issues here. I think that North Korea, Iran both continue to be bad actors, and the president is somebody who’s going to always look for ways to protect Americans, and he’s not going to dictate what those actions may look like.”
Suddenly, Mr. Trump’s preprandial banter took on an ominous tone. Maybe he was foreshadowing war with North Korea, which he has already threatened with “fire and fury” if the reclusive country aimed its missiles at the United States. Or perhaps he was predicting a clash with Iran, a week before he is expected to disavow the nuclear deal negotiated by his predecessor, Barack Obama.
“He certainly doesn’t want to lay out his game plan for our enemies,” Ms. Sanders declared.
The crazy ideas in my head inspired by a RISC-V story
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.
U.S. House of Representatives Passes 20-Week Abortion Ban
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.
Skin Flutes
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.
Flutes "stained with a man's bodily fluids" issued to California schoolchildren
Flutes Across the World: Japan Edition.
