Re: kernel after 5.0-rc2 may not boot using BBL

[Palmer Dabbelt <palmer@sifive.com>]

On Mon, 11 Feb 2019 17:24:05 PST (-0800), Michael Clark wrote:
>
>
> On 11/02/19 9:45 PM, Anup Patel wrote:
>> On Mon, Feb 11, 2019 at 1:55 PM Christoph Hellwig <hch@infradead.org> wrote:
>>>
>>> On Sat, Feb 09, 2019 at 09:00:27AM +0530, Anup Patel wrote:
>>>> IMHO, best solution would be to use mature open-source bootloader as
>>>> payload (i.e. U-Boot or similar) and always boot Linux from bootloader. Using
>>>> Linux as BBL/OpenSBI payload can still continue to exist but it can be more
>>>> of a developer usage.
>>>
>>> Yes, that is a good long term plan.  But in the meantime we should not
>>> gratiously break the precious setups people got working..
>
> This has been a longstanding issue. I believe some Berkeley graduates
> are in control of the repos (some of them are very intelligent young
> Doctors). However, the Berkeley software doesn't even version numbers.
> We can't call the release management shocking because it is
> non-existent. i.e.it is not even at the linux-0.11 style versioning
> scheme, (although Linus didn't have version control hence tarball's).
> Methinks they don't want CVEs being assigned as that would taint their
> impeccable security reputation. For example, one can't really assign a
> CVE to master:HEAD on a git repo. One needs an actual release. I am sure
> it is deliberate. That said, assigning CVEs to students, with them
> having a black mark at the start of their careers is probably also a bad
> idea.
>
> I think these gratuitous breakages are a ploy, either to demonstrate how
> easily trust can be subverted. i.e. the breakages are actually to troll
> long-standing kernel overdevelops, showing how easy it is to slip in
> breaking changes using the "trusted lieutenants" model, and it is not
> really fixable until someone with release engineering experience takes
> control of the foundation repositories, or the students step up and take
> responsibility for their work, adding due professionalism, such as CI.
> They are getting paid now.

I'd like to assure everyone that the breakage was not intentional.  We're all 
just doing our best to make things work here and unfortunately somethings 
things still break.  Of course it's better when things don't break, but there's 
always a risk of breaking something whenever a change is introduced.  In this 
case we were testing against BBL, it just turns out that the Linux 
configuration that everyone was testing didn't trigger the bug before the patch 
got merged.

As far as I understand it this is what the merge window / RC process was 
designed for: during the merge window we accept changes that are then 
stabilized over the course of the RCs.  It's better to not rely on that safety 
net, but in this case it did work.

> Ideal situation would be gated repository with CI in front that locks
> out changes that regress any of a suite of tests run against the open
> source tools (and now simulation of the underlying open source chip and
> its firmware), core libraries and the kernel. I am aware that some of
> the breakages are deliberate based on traces in GitHub issues, and
> artifacts in the git history. This century's beginning is marked by the
> ubiquity of CI, well, certainly the last decade, so I see no reason why
> it should not be applied here, as these changes would not have made it
> into a project that has CI.
>
> Twerps. They need a punch. Not a gut punch. Just a friendly but firm

Please keep things civil.  So far I've been able to get away without properly 
reading the code of conduct and I'd like to keep it that way if possible :)

> punch, in the shoulder. Serious, but not hard enough to cause any
> permanent injury. In the right shoulder because the left shoulder has
> bursitis, and not onto the bone as that would hurt one's fist. We need
> to think about how to achieve this with a little finesse. Phone books
> don't leave bruises but they are bulky to carry around, especially if
> you lure one of these developers into a bar in a social setting. The
> Phone book will look out of place. I think just a regular firm fist
> punch would be best. We don't want assault charges and we certainly
> wouldn't want an email trail leading back to someone threatening punches
> to key members of the RISC-V community. That could be damaging (insert
> emoji :Grinning Face With Smiling Eyes:). Anyway, they can't get to me
> because I am in another country, so probability of me receiving a
> physical punch is very low, so just a virtual punch, and it would be a
> round of exchanging punches. Like I punch you, you punch me back sort of
> thing. i.e. it needs to be fair.
>
>> The kernel breakage totally unintentional. I had done all testing using BBL
>> and OpenSBI with Linux compiled using defconfig but never saw the issue.
>
> I agree with Christoph.
>
> It is no excuse. This is bad because it shows lack of basic testing.
> It's like nobody boot tests riscv-qemu with BBL, which is where all of
> the work on PMP is. In this century, most mature adults are using CI so
> these sorts of changes would never even make it into the master branch
> after checks are made against the PR. I think they are just
> demonstrating how easily trust without verification can be subverted, as
> they have visibly sabotaged attempts to have CI set up for the RISC-V
> port of the kernel, tools and C library. I have evidence of this in
> writing. The commit in BBL that breaks PMP also has terrible code smell
> as it is hidden out-of-line from the existing PNP code, is hard-coded
> for a number of registers that differs from the specification, and the
> writing style is quite different from the other code. We can't even rule
> out the possibility of a forged commit given sha128 weaknesses. There
> are so many vectors for which they can inject breaking changes that go
> undetected without CI. Of course if it was written in ink, we could do
> hand-writing analysis, but in this case it is GitHub keys.
>
> Also, the OpenSBI plan has somehow been made fiat by the RISC-V
> Foundation by recently appearing in its GitHub organization, however, I
> am unsure that it was actually an agreed upon direction. There was no
> public review period. It just appeared from nowhere. Certainly there are
> different consensus processes operating here, one an orthodox one and
> one a heterodox one.
>
> I personally think merges need to be done by a bot, and; the consensus
> from the adults on the mailing list is that SBI should not be required
> for what should be accomplished by drivers; perhaps only to maintain
> backwards compatibility with the silicon that hardly anyone can get
> their hands on. Before I got fired, I was working on the CLIC which
> potentially allowed S-mode to have its own timers and IPIs. I personally
> think not giving S-mode timers and IPIs is kind of dumb. The number of
> flops for another timer and interrupt source is tiny. That said, good
> job from many other angles as there is an open source chip that runs
> Linux and we have Debian. The SBI firmware issue is just roughness
> around the edges and we can't expect everything to be perfect on day
> one, and it shows one can save a few flops (i.e. nanocents) at the
> expense of transitioning to RISC code in M-mode as micro-code using the
> memory bus for state versus one more timer comparator register.
>
> If we have CI, we should test riscv-pk. Many folk are using it and there
> are several derivatives. It is the original boot loader for RISC-V. I've
> been a BBL user for several years. I think it was Dec 2015 when I
> ordered an FPGA to run lowRISC untethered.
>
> BTW Palmer, Thanks for firing me. Last time I had a difficult boss I
> quit, but getting fired is actually better, because we have a 3 month
> stand down for our social security system here in NZ. If one voluntarily
> leaves one's job, one is not entitled to our unemployment benefit. If
> one gets fired, then one is entitled to the benefit immediately. You
> still need to pay us for the work up until December. I guess I got fired
> because I was super annoyed by being blocked from working on CI which
> was in my contract as an exhibit, and was what I volunteered to do. I
> didn't really want to do it anyhow; it is work; it's just something I
> have experience with (Cloud CI yada yada yada). The current setup is
> really bad from what I've used commercially. Also working on Open Source
> under an NDA is a bit weird too. One can be fired at any time for no
> reason. Much worse if I was in California on an H1B, where one
> essentially needs to leave the country if one gets fired. In this case,
> I just need to move somewhere cheaper to live, oddly enough Palmerston
> North (it's not really possible to survive in Auckland on social
> security as rents are comparatively high; like the Bay Area). Lucky I
> was fired before moving. That be much worse for my partner and step-son
> if I was fired after already moving to California. Hope you find someone
> to look after QEMU. If I was getting paid, I wouldn't mind to do some
> part-time work on CI, but I have another project that I want to work on.
>
> Regards,
>
> Michael.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv