From: mick@ics.forth.gr (Nick Kossifidis) To: linux-riscv@lists.infradead.org Subject: [sw-dev] SBI extension proposal v2 Date: Sat, 10 Nov 2018 19:54:56 +0200 [thread overview] Message-ID: <357bd90554bff728520be2ee69d802c1@mailhost.ics.forth.gr> (raw) In-Reply-To: <CAOesGMjVFGLfqVqmsK6V88cdTxmN_CAEhDey8nxKOeTYHC69jA@mail.gmail.com> ???? 2018-11-10 19:41, Olof Johansson ??????: > On Sat, Nov 10, 2018 at 8:46 AM ron minnich <rminnich@gmail.com> wrote: >> >> At Google and other places, we've been struggling now for years with >> overly complex firmware that is implemented incorrectly, enabling >> exploits and other bad things. The list of things vendors get wrong in >> firmware, both enabling exploits and enabling others to enable >> exploits, is long and it continues to this day. There is an >> unbelievable amount of money out there all involving firmware >> exploits, very little of it involving nice people. >> >> I'm currently working on deleting all use of the x86 version of M >> mode, i.e. SMM. There are many proposals out there for deleting SMM >> from the architecture. I've also shown at a talk in 2017 how we could >> redirect SMM interrupts back into the kernel. We're also removing all >> use of callbacks into UEFI on x86. We're almost there. >> >> Which is why I'm a bit unhappy to see this (to me) cancerous growth in >> proposals for M- mode code. PPP in firmware? Really? multiple serial >> devices? really? We've been here before, in the 1970s, with something >> called the BIOS. If you're not familiar with it, go take a look, or >> you can take my word for it that these proposals implement that idea. >> We spent over 20 years freeing ourselves from it on x86. Why go back >> to a 50 year old model on a CPU designed to be in use for 50 years? >> >> My early understanding of M mode was that it was an Alpha PALCode like >> thing, enabling access to resources that were behind a privilege wall. >> I did not like it that much, but I was OK: it was very limited in >> function, and the kernel could replace it, or at least measure it. I >> also accept that every cpu vendor uses m mode like things (e.g. ARM >> TF) for reasonable purposes and also (let's be honest here) for >> dealing with chipset mistakes. But that does not mean you need to >> recreate BIOS. >> >> The SBI should be hard to add to, deliberately. It should be used only >> when there are no possible alternatives. It needs to be open source >> and held in common. It should be possible for a kernel to replace or >> at least measure it. And, further, there needs to be some work done on >> why you add to it, and why you don't, with bias against adding to it. >> This proposal works against those ideals, as it explicitly enables >> vendor-specific forks of the SBI. Sure, this can happen, but why make >> it so easy? > > There's a tension between letting people do the messy things that real > hardware sometimes needs without polluting higher layers in the > software stack, and letting them do too much of things that _should_ > be handled in the upper layers. I have yet to find a solution that > doesn't need tweaking over time, the pendulum tends to swing back and > forth into "too far" in both directions sometimes. > > The case of console is in this case pretty simple: It's intended for > early boot for very simplistic environments (before the rest of the > kernel is up, etc). Keeping the SBI console around beyond early boot, > and somehow trying to optimize for it for those use cases is a > misdirected effort; that's what native drivers are for. > > Having to do fine-grained arbitration of device ownership between > firmware and kernel at runtime is usually error prone and awkward and > best to avoid. > > +1 >> p.s. For interleaving debug and console output firmware, use the >> oldest trick in the book: ASCII is 7 bits. Since console out is 8 >> bits, reserve 128 values for console out, and 128 for debug stream, >> and if the debug stream needs 8 bit for some words, you know what to >> do. It's very easy and doesn't require that we add multiple UART >> support to SBI. > > Sure, it helps for 2 channels. And then beyond that you need a more > complex protocol. Either way, it's not a problem we need to solve here > and now. > +1, most people will just use minicom/picocom to do their job, not implement a protocol over serial for splitting main console from debug console.
WARNING: multiple messages have this Message-ID (diff)
From: Nick Kossifidis <mick@ics.forth.gr> To: Olof Johansson <olof@lixom.net> Cc: Mark Rutland <mark.rutland@arm.com>, Christoph Hellwig <hch@infradead.org>, Damien.LeMoal@wdc.com, olof johansson <olof.johansson@gmail.com>, alankao@andestech.com, abner.chang@hpe.com, atish.patra@wdc.com, Anup Patel <anup@brainfault.org>, Palmer Dabbelt <palmer@sifive.com>, Alexander Graf <agraf@suse.de>, zong@andestech.com, rminnich@gmail.com, sw-dev@groups.riscv.org, paul.walmsley@sifive.com, mick@ics.forth.gr, Alistair.Francis@wdc.com, lkcl@lkcl.net, linux-riscv@lists.infradead.org, Andrew Waterman <andrew@sifive.com> Subject: Re: [sw-dev] SBI extension proposal v2 Date: Sat, 10 Nov 2018 19:54:56 +0200 [thread overview] Message-ID: <357bd90554bff728520be2ee69d802c1@mailhost.ics.forth.gr> (raw) Message-ID: <20181110175456._3-659h0hh9P4Z0ITcZV09pM7rF3qonXHKTykOCJDnk@z> (raw) In-Reply-To: <CAOesGMjVFGLfqVqmsK6V88cdTxmN_CAEhDey8nxKOeTYHC69jA@mail.gmail.com> Στις 2018-11-10 19:41, Olof Johansson έγραψε: > On Sat, Nov 10, 2018 at 8:46 AM ron minnich <rminnich@gmail.com> wrote: >> >> At Google and other places, we've been struggling now for years with >> overly complex firmware that is implemented incorrectly, enabling >> exploits and other bad things. The list of things vendors get wrong in >> firmware, both enabling exploits and enabling others to enable >> exploits, is long and it continues to this day. There is an >> unbelievable amount of money out there all involving firmware >> exploits, very little of it involving nice people. >> >> I'm currently working on deleting all use of the x86 version of M >> mode, i.e. SMM. There are many proposals out there for deleting SMM >> from the architecture. I've also shown at a talk in 2017 how we could >> redirect SMM interrupts back into the kernel. We're also removing all >> use of callbacks into UEFI on x86. We're almost there. >> >> Which is why I'm a bit unhappy to see this (to me) cancerous growth in >> proposals for M- mode code. PPP in firmware? Really? multiple serial >> devices? really? We've been here before, in the 1970s, with something >> called the BIOS. If you're not familiar with it, go take a look, or >> you can take my word for it that these proposals implement that idea. >> We spent over 20 years freeing ourselves from it on x86. Why go back >> to a 50 year old model on a CPU designed to be in use for 50 years? >> >> My early understanding of M mode was that it was an Alpha PALCode like >> thing, enabling access to resources that were behind a privilege wall. >> I did not like it that much, but I was OK: it was very limited in >> function, and the kernel could replace it, or at least measure it. I >> also accept that every cpu vendor uses m mode like things (e.g. ARM >> TF) for reasonable purposes and also (let's be honest here) for >> dealing with chipset mistakes. But that does not mean you need to >> recreate BIOS. >> >> The SBI should be hard to add to, deliberately. It should be used only >> when there are no possible alternatives. It needs to be open source >> and held in common. It should be possible for a kernel to replace or >> at least measure it. And, further, there needs to be some work done on >> why you add to it, and why you don't, with bias against adding to it. >> This proposal works against those ideals, as it explicitly enables >> vendor-specific forks of the SBI. Sure, this can happen, but why make >> it so easy? > > There's a tension between letting people do the messy things that real > hardware sometimes needs without polluting higher layers in the > software stack, and letting them do too much of things that _should_ > be handled in the upper layers. I have yet to find a solution that > doesn't need tweaking over time, the pendulum tends to swing back and > forth into "too far" in both directions sometimes. > > The case of console is in this case pretty simple: It's intended for > early boot for very simplistic environments (before the rest of the > kernel is up, etc). Keeping the SBI console around beyond early boot, > and somehow trying to optimize for it for those use cases is a > misdirected effort; that's what native drivers are for. > > Having to do fine-grained arbitration of device ownership between > firmware and kernel at runtime is usually error prone and awkward and > best to avoid. > > +1 >> p.s. For interleaving debug and console output firmware, use the >> oldest trick in the book: ASCII is 7 bits. Since console out is 8 >> bits, reserve 128 values for console out, and 128 for debug stream, >> and if the debug stream needs 8 bit for some words, you know what to >> do. It's very easy and doesn't require that we add multiple UART >> support to SBI. > > Sure, it helps for 2 channels. And then beyond that you need a more > complex protocol. Either way, it's not a problem we need to solve here > and now. > +1, most people will just use minicom/picocom to do their job, not implement a protocol over serial for splitting main console from debug console. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2018-11-10 17:54 UTC|newest] Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-10 2:42 SBI extension proposal v2 Atish Patra 2018-11-10 2:42 ` Atish Patra 2018-11-10 5:12 ` [sw-dev] " Luke Kenneth Casson Leighton 2018-11-10 5:12 ` Luke Kenneth Casson Leighton 2018-11-10 14:50 ` Nick Kossifidis 2018-11-10 14:50 ` Nick Kossifidis 2018-11-10 15:48 ` Luke Kenneth Casson Leighton 2018-11-10 15:48 ` Luke Kenneth Casson Leighton 2018-11-10 16:46 ` ron minnich 2018-11-10 16:46 ` ron minnich 2018-11-10 17:40 ` Luke Kenneth Casson Leighton 2018-11-10 17:40 ` Luke Kenneth Casson Leighton 2018-11-10 17:41 ` Samuel Falvo II 2018-11-10 17:41 ` Samuel Falvo II 2018-11-10 17:42 ` Luke Kenneth Casson Leighton 2018-11-10 17:42 ` Luke Kenneth Casson Leighton 2018-11-10 17:51 ` Samuel Falvo II 2018-11-10 17:51 ` Samuel Falvo II 2018-11-10 17:55 ` Luke Kenneth Casson Leighton 2018-11-10 17:55 ` Luke Kenneth Casson Leighton 2018-11-10 18:03 ` Samuel Falvo II 2018-11-10 18:03 ` Samuel Falvo II 2018-11-10 17:43 ` Samuel Falvo II 2018-11-10 17:43 ` Samuel Falvo II 2018-11-10 17:41 ` Olof Johansson 2018-11-10 17:41 ` Olof Johansson 2018-11-10 17:47 ` Luke Kenneth Casson Leighton 2018-11-10 17:47 ` Luke Kenneth Casson Leighton 2018-11-10 17:59 ` Nick Kossifidis 2018-11-10 17:59 ` Nick Kossifidis 2018-11-10 18:01 ` ron minnich 2018-11-10 18:01 ` ron minnich 2018-11-10 19:33 ` Luke Kenneth Casson Leighton 2018-11-10 19:33 ` Luke Kenneth Casson Leighton 2018-11-10 19:39 ` Luke Kenneth Casson Leighton 2018-11-10 19:39 ` Luke Kenneth Casson Leighton 2018-11-11 3:15 ` Nick Kossifidis 2018-11-11 3:15 ` Nick Kossifidis 2018-11-11 7:14 ` Luke Kenneth Casson Leighton 2018-11-11 7:14 ` Luke Kenneth Casson Leighton 2018-11-11 13:17 ` Nick Kossifidis 2018-11-11 13:17 ` Nick Kossifidis 2018-11-12 2:08 ` Palmer Dabbelt 2018-11-12 2:08 ` Palmer Dabbelt 2018-11-10 18:02 ` Olof Johansson 2018-11-10 18:02 ` Olof Johansson 2018-11-10 19:34 ` Luke Kenneth Casson Leighton 2018-11-10 19:34 ` Luke Kenneth Casson Leighton 2018-11-13 1:22 ` Michael Clark 2018-11-13 1:22 ` Michael Clark 2018-11-10 17:54 ` Nick Kossifidis [this message] 2018-11-10 17:54 ` Nick Kossifidis 2018-11-10 17:59 ` ron minnich 2018-11-10 17:59 ` ron minnich 2018-11-11 3:58 ` Atish Patra 2018-11-11 3:58 ` Atish Patra 2018-12-02 6:18 ` Benjamin Herrenschmidt 2019-01-28 12:31 ` Alexander Graf 2019-01-28 16:33 ` Luke Kenneth Casson Leighton 2019-01-28 16:38 ` Alexander Graf 2019-01-28 16:47 ` Nick Kossifidis 2019-01-28 19:43 ` Alexander Graf 2019-01-28 19:47 ` Atish Patra 2019-01-28 19:48 ` Alexander Graf 2019-01-28 19:40 ` ron minnich 2019-01-28 19:55 ` Alexander Graf 2019-01-28 20:18 ` ron minnich 2019-01-28 20:37 ` Alexander Graf 2019-01-28 22:23 ` ron minnich 2019-01-29 8:53 ` Alexander Graf 2019-01-29 15:52 ` ron minnich 2019-01-28 23:46 ` Luke Kenneth Casson Leighton 2019-01-28 23:22 ` Bruce Hoult 2019-01-29 0:03 ` Luke Kenneth Casson Leighton 2019-01-29 4:28 ` ron minnich [not found] ` <CANs6eMk4z-ZibLW_5o03onu8AQe23uMa2hSieceHFqKS7igLDQ@mail.gmail.com> 2019-01-30 0:05 ` Luke Kenneth Casson Leighton 2019-01-30 0:17 ` ron minnich 2019-01-30 0:49 ` Bruce Hoult 2019-01-30 3:15 ` Luke Kenneth Casson Leighton [not found] ` <09bede45-6ecf-4ded-8615-0be38aac33fc@groups.riscv.org> 2019-01-29 3:58 ` Samuel Falvo II 2019-01-29 4:33 ` ron minnich 2019-02-05 22:29 ` Benjamin Herrenschmidt 2019-02-05 23:02 ` Luís Marques 2019-02-06 7:03 ` ron minnich 2019-02-06 7:54 ` Damien Le Moal 2019-02-07 3:56 ` Paul Walmsley 2019-02-07 7:17 ` Anup Patel 2019-02-07 7:19 ` Anup Patel 2019-01-29 22:41 ` Palmer Dabbelt 2018-11-10 17:43 ` Nick Kossifidis 2018-11-10 17:43 ` Nick Kossifidis 2018-11-10 17:51 ` Luke Kenneth Casson Leighton 2018-11-10 17:51 ` Luke Kenneth Casson Leighton 2018-11-10 5:36 ` David Abdurachmanov 2018-11-10 5:36 ` David Abdurachmanov [not found] ` <CA++6G0BTdybjhqaXm9EhAz0HsgpwfozK6OEL7DuzbS48RbEChA@mail.gmail.com> 2018-11-10 15:09 ` Nick Kossifidis 2018-11-10 15:09 ` Nick Kossifidis 2018-11-12 4:33 ` Nick Kossifidis 2018-11-12 4:33 ` Nick Kossifidis 2018-12-04 23:22 ` [sw-dev] " Atish Patra
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=357bd90554bff728520be2ee69d802c1@mailhost.ics.forth.gr \ --to=mick@ics.forth.gr \ --cc=linux-riscv@lists.infradead.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).