Announcement

Collapse
No announcement yet.

Some Of The Early Ideas For Intel's New FreeBSD Improvement Effort

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by audi100quattro View Post
    They actually did design their own chipset in FreeBSD kernel modules or userspace applications using SATA/Ethernet/USB and PCIe 4x of the ARM SoC. If the only link to the APU is the PCIe 4x link... then no peripheral is going be reading/writing to main memory directly anytime without the south-bridge explicitly doing the reading/writing as the middle man. If something like the switch hack shows up, just fix the middle man. It's pretty smart. No wonder reverse engineering is a pain, and it's been more secure than the mod-chip friendly PS2 and CFW friendly PS3 (at-least at the end of it's life).
    From what I gathered from the slides it uses PCIe to allow DMA over to the system memory (as PCIe does allow DMA) https://fail0verflow.com/media/33c3-slides/#/45 https://fail0verflow.com/media/33c3-slides/#/46 which they broke when they enabled IOMMU to mask the madness of the "chipset" and remap it to linux drivers https://fail0verflow.com/media/33c3-slides/#/48 https://fail0verflow.com/media/33c3-slides/#/49 and had to patch IOMMU to be 31bit so the thing could work https://fail0verflow.com/media/33c3-slides/#/50

    If you wanted that isolation both x86 and ARM have IOMMU (Intell calls it VT-d), which isolates DMA peripherals to their own RAM allocation and does not allow them to look at something else.

    Afaik most modern stuff is hacked from userspace, through Webkit vulnerabilities and then using kernel vulnerabilities, which in this case were found by looking at FreeBSD 9 ones as the PS4 is still a FreeBSD derivative https://cturt.github.io/ps4.html

    The latest Switch hack was done by shorting pins because the Tegra's BootROM was still left default so it can be talked with by shorting its pins to boot something else. Before that it was hacked by exploiting Webkit. I'm not sure how using a SoC southbridge can protect you from that.

    The PS4 also has a rest mode, which will only download games/updates and charge USB controllers. This is the Southbridge running with the APU off. 256MB RAM is enough to download to the HD.
    Are you sure of this or are just speculating? Because x86 hardware can go in very low-power modes too and it could easily shut down the GPU in the APU and run only 1 core to deal with these basic tasks.

    Comment


    • #22
      unapproved post for audir8 above

      also
      They actually did design their own chipset in FreeBSD kernel modules or userspace applications using SATA/Ethernet/USB and PCIe 4x of the ARM SoC.
      No that's not what I meant. I meant paying the licenses to use the hardware blocks in the design stage to actually have their own SATA/Ethernet/USB controllers inside their own custom "chipset" chip or inside the APU.

      I meant hardware design. Doing a bridge from a Marvell SoC and remapping stuff with software is much easier, and orders of magnitude cheaper than actual hardware design.

      Comment


      • #23
        Originally posted by UnholyViking View Post

        Yup and no one is talking about technical merits. The level of discussion is that of adolescent idiots. No one is backing stuff up with facts or references.

        As a user of (primarily) FreeBSD I think the FOSS community ows alot the Linux kernel even though I think the Linux kernel and much of the userland is a mess. And the GPL vs MIT/BSD license BS is pretty much stupid as well "Companies does not give back when they don't use GPL". Well, they do.

        https://v4.freshbsd.org/search?q=Netflix&project[]=freebsd&repository[]=src&sort=commit_date
        https://v4.freshbsd.org/search?q=Mic...rt=commit_date
        https://v4.freshbsd.org/search?q=Int...rt=commit_date
        https://v4.freshbsd.org/search?q=Goo...rt=commit_date
        https://v4.freshbsd.org/search?q=Jun...rt=commit_date

        And the list goes on.


        I for one would like to see more talks about technical merits, and if you have a claim, back it up with a benchmark.
        Phoronix BSD forum threads are usually riddled with responses from 1-3 prominent Phoronix trolls. Usually these threads are ignored and left alone by this Linux-enthusiast community (except for the trolls).

        Just scroll through this thread and observe most of the 20+ responses originate from 1-2 people. Remember those names well and do some subconscious filtering next time you read the forum.

        Comment


        • #24
          Originally posted by starshipeleven View Post
          Are you sure of this or are just speculating? Because x86 hardware can go in very low-power modes too and it could easily shut down the GPU in the APU and run only 1 core to deal with these basic tasks.
          Suspend to ram, which happens in rest mode if you have a game running, doesn't require the APU to be on, and I don't believe you could get consumption as low as 10W even if 1 Jaguar core was running at reduced speed. Running a 3W ARM SoC, 3-5W for USB/HDD/Wifi, and 1-2W for 12GB of RAM makes way more sense. IMPI-like features shouldn't need anything more than the ARM SoC.

          This hack to rest mode says rest mode only uses the ARM SoC and not the main SoC, and has a separate bootloader/kernel controlled by Sony:
          https://gbatemp.net/threads/ps4-5-xx...vealed.496086/

          Rest mode does complicate the chipset, though it's little more than IPMI. It makes sense for it to be on the chipset. Doing DMA in C does give you more control over unforeseen/unexpected potential hacks, and I would say stops DMA attacks over bad controllers that exist. The webkit based attacks get you root, but it's getting any private keys that will let you do CFW and almost anything else you'd want to do at that point. The pdf linked from the above link uses both to dump the ARM SoC bootloader letting you run a custom kernel in rest mode, which is a first for the PS4. Apparently there is an open orbis project to let you run custom firmware/userspace, though I don't think they have anything that's persistent across reboots yet from my reading.

          The BIOS/BootROM is just another peripheral if you ask me, and Sony has done a much better job of securing peripherals than Nvidia or Nintendo. They're different designs since Sony has two bootloaders to worry about and they have almost total control over how the APU is booted through the ARM SoC chipset (if it's done that way).

          It is almost the end of the line for the PS4, though I think Sony has succeeded unless pirating happens like PS1/2 or cheating in multiplayer takes off. Another victory for DRM/Security if you ask me.
          Last edited by audir8; 17 June 2018, 12:12 PM.

          Comment


          • #25
            Originally posted by Kazuo-Omura View Post
            This is good news and I'm happy to see on of the most vital competitors to Linux getting some love from Intel.

            On these petty arguments between FreeBSD supporters and Linux supporters I try to just ignore them. Especially after reading Pawlerson's post history I want no part of that.

            All I'm for is competition and the status quo being constantly reworked, in particular I'm hoping all of this RedHat-ware that has been hoisted onto the modern Linux desktop, I.e. dbus, gstreamer, polkit etc. Be replaced by something far more cohesive that actually fixes the underlying issues of the Linux kernel, I.e.:

            The lack of a good STREAMS protocol implementation rather than trying to put an object-based IPC into an OS concept it doesn't work well in.

            The lack of good media and audio libraries as well as poor kernel support (ALSA is rubbish due to its blocking I/O, and Pulse introduces latency and other issues by trying to fix it.)

            And application developers and distro devs reinventing the wheel regarding desktop security while essentially chasing their own tails in a circle.

            Not to say the BSDs do not have serious issues or that Solaris/illumos or any other OS doesnt have them itself, but a cohesive design philosophy is something the Linux ecosystem lacks.
            A few quick questions:

            1. What benefits does STREAMS have over AF_UNIX?
            2. Why does not object-passing work well as an OS concept?
            3. What do you mean by ALSA using blocking I/O? You open the alsa device in non-blocking mode with SND_PCM_NONBLOCK so you must obviously mean something else.
            4. How would it be possible to support non-dropping of audio packets without introducing latency (aka buffering) for user-space programs that does not send the audio data fast enough?

            Comment


            • #26
              Originally posted by monraaf

              It is x86, it's just not a PC.

              Some people still don't understand that platform and architecture are not the same thing. A machine can be x86, but it doesn't have to be a PC. Having a non-PC platform is just not so common that's why most people assume x86 is equivalent to a PC.

              The Linux kernel supports multiple x86 platforms. One of them is the PC (the most common x86 platform) but others also include SGI's UV NUMA supercomputers.

              Just have a look at what platforms the Linux kernel supports when configuring the kernel for the x86 architecture.
              It has something called unified memory architecture, which you won't precisely find from PC's and which is one thing making it different from PC hardware, even if we ignore other changes, like lack of UEFI/BIOS. Yeah, it's cpu is x86, is it "regular x86 hardware" as repurposed PC, no. There are probably enough changes made to the original FreeBSD 9 code that instead of porting over from Sony (even if they released sources) - it would be easier to rewrite from scratch. If there is anything to rewrite in the first place - it's not like console needs abstraction layers like Windows's DirectX - it's standardized hardware and you could write closer to metal.
              Last edited by aht0; 17 June 2018, 04:56 PM.

              Comment


              • #27
                > What benefits does STREAMS have over AF_UNIX?

                By AF_UNIX I assume you mean the socket family. Sockets, by design are either client-server (i.e. mysql.sock for a mysql server) or bidirectional. What dbus does is overlay an MS-COM like object model and bus over the socket concept. STREAMS is capable of using a process stack to provide multi-directional IPC without overlaying user-space components over it. It's simpler, older, and worked on IRIX and Solaris for decades. Is it a perfect design? No, but neither is the UNIX concept - it has plenty of flaws I won't get into here.

                > Why does not object-passing work well as an OS concept?

                You seem to have misinterpreted me. UNIX, as a concept, is not an object-based OS, and I was trying to say that shoe-horning object-orientedness on to an OS concept that shuns it is wasted effort and breaks the philosophy that was originally intended. If you're going to try and introduce object models, it would be better to start with an OS that is designed for it, otherwise you get the clusterfuck that is macOS eventually and logically.

                > What do you mean by ALSA using blocking I/O? You open the alsa device in non-blocking mode with SND_PCM_NONBLOCK so you must obviously mean something else.

                ALSA's design is as such that multiple inputs and mixing aren't handled efficiently because of the way that Linux's ALSA subsystem exposes the sound hardware. Compared to OSS, it's a design flaw and the reason that Pulseaudio became a popular workaround - Pulse essentially grabs hold of the device and handles mixing in userspace - the main gripes I have with Pulse is that it's a knockoff of Apple's CoreAudio, down to the name. Is it a horrible product? In its early days absolutely. It's better now, but I think that it's still a poor design philosophy (I'm typing this from a Mint Linux install, though, so I do tolerate it.)

                > How would it be possible to support non-dropping of audio packets without introducing latency (aka buffering) for user-space programs that does not send the audio data fast enough?

                My answer would be to not use those programs, but really you bring up a good point here. My main gripe is that far more spartan OSes have mastered what Linux can't seem to get a grip on. My old SGI Octane running IRIX handles everything I need for audio production (one of my hobbies is that I'm a synth player) and it's audio implementation is over 20 years old - handles multiple inputs and with appropriately chosen programs, I've not had a single nasty experience with it.

                I'm also one of those who doesn't blame an OS when it doesn't support the hardware the user tries to throw at it - but that's probably because I choose the hardware depending on what OS I'm gonna use. I don't get mad when a shiny Coffee Lake i7 isn't supported by RISC OS, or when I can't run Windows 10 on a Commodore 64. So I generally say, pick well designed tools to use on a well-designed OS for an intended function.

                And I appreciate you responding like a normal human being instead of the edgy teenage cultist that is the likes of our usual assortment of people who comment here.

                I don't pretend to be an expert in these areas, I'm not a developer, but I can read code and understand technical documentation so I'm relatively familiar with the methods by which various OSes work on a certain level.

                Comment


                • #28
                  Originally posted by audi100quattro View Post
                  It is almost the end of the line for the PS4, though I think Sony has succeeded unless pirating happens like PS1/2 or cheating in multiplayer takes off. Another victory for DRM/Security if you ask me.
                  I actually agree with this.
                  • Pirating is very rare on the PS4 - Great for Sony and their publishers
                  • Jailbreaking and Linux is absolutely rampant on the PS4 - Great for technical consumers

                  (https://github.com/valentinbreiz/PS4-Linux-Loader)

                  Other than the Switch that is pretty much an open platform these days. I am very happy with the balance that the PS4 has. I personally use my PS4 as my torrent media center and Git server

                  Comment


                  • #29
                    kpedersen I have a few questions... Is the Linux install persistent? What happens when you turn it on/off? Does it go back to booting Sony firmware if you remove the USB drive and put it on a normal network? I'm guessing suspend/resume doesn't work. Couldn't figure out answers to this, though progress has speeded up I guess in the last 6 or so. Thanks.

                    Comment


                    • #30
                      audir8, If you reboot the machine it goes back to booting the PS4 Orbis OS. I actually get my router (a WRT variant) to push the payload on reboot. It is quite an elaborate setup but it works pretty well and can forget it is there
                      Other than that I don't run it on a network that is particularly special. If I ever want to run it to play games, I simply unplug it from the network, insert a disk and restart.

                      Admittedly I have not tried to suspend it. To be fair the only OSes I have even seen suspend working well on are OpenBSD and Windows on a x61 Thinkpad. I don't even bother trying on anything else.

                      Yes, we had to wait a long while for the exploit to work on anything other than 1.x firmware. Since the 4.x line, Sony hasn't bothered trying to attack our freedom again by patching it up.

                      Comment

                      Working...
                      X