* kernel after 5.0-rc2 may not boot using BBL
@ 2019-02-08 6:08 Atish Patra
2019-02-08 8:32 ` Christoph Hellwig
0 siblings, 1 reply; 12+ messages in thread
From: Atish Patra @ 2019-02-08 6:08 UTC (permalink / raw)
To: linux-riscv; +Cc: Andreas Schwab, Anup Patel
If you are building a larger kernel image, it may not boot using BBL
after 5.0-rc2. It works fine with OpenSBI though.
Here is the reasoning in case anybody else is facing the same issue.
The following patch was added 5.0-rc2 which helps reduce the flat image
size for Linux kernel.
"22e6a2e1 RISC-V: Make BSS section as the last section in vmlinux.lds.S"
As the BSS section is moved to the end of the ELF, flat image will not
include it. As BBL copies the DTB at the next 2MB page boundary, BSS
section may overlap with DTB address. Kernel clears BSS section during
early boot which may clear the DTB as well leading to a boot failure.
OpenSBI always copies the DTB far ahead in the memory (0x82200000).
That's why you won't see any issue with OpenSBI.
Here is a BBL fix that can solve this problem. I will submit a PR to
riscv-pk.
diff --git a/bbl/bbl.c b/bbl/bbl.c
index 1b96a9d5..0d448d82 100644
--- a/bbl/bbl.c
+++ b/bbl/bbl.c
@@ -14,7 +14,7 @@ static uintptr_t dtb_output()
{
extern char _payload_end;
uintptr_t end = (uintptr_t) &_payload_end;
- return (end + MEGAPAGE_SIZE - 1) / MEGAPAGE_SIZE * MEGAPAGE_SIZE;
+ return (end + 16 * MEGAPAGE_SIZE - 1) / MEGAPAGE_SIZE * MEGAPAGE_SIZE;
}
Thanks Anup for the explanation and above fix.
Regards,
Atish
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: kernel after 5.0-rc2 may not boot using BBL
2019-02-08 6:08 kernel after 5.0-rc2 may not boot using BBL Atish Patra
@ 2019-02-08 8:32 ` Christoph Hellwig
2019-02-08 9:02 ` Anup Patel
0 siblings, 1 reply; 12+ messages in thread
From: Christoph Hellwig @ 2019-02-08 8:32 UTC (permalink / raw)
To: Atish Patra; +Cc: Andreas Schwab, linux-riscv, Anup Patel
On Thu, Feb 07, 2019 at 10:08:14PM -0800, Atish Patra wrote:
> If you are building a larger kernel image, it may not boot using BBL after
> 5.0-rc2. It works fine with OpenSBI though.
>
> Here is the reasoning in case anybody else is facing the same issue.
>
> The following patch was added 5.0-rc2 which helps reduce the flat image size
> for Linux kernel.
>
> "22e6a2e1 RISC-V: Make BSS section as the last section in vmlinux.lds.S"
>
> As the BSS section is moved to the end of the ELF, flat image will not
> include it. As BBL copies the DTB at the next 2MB page boundary, BSS
> section may overlap with DTB address. Kernel clears BSS section during early
> boot which may clear the DTB as well leading to a boot failure.
Breaking everyones (qemu) setups that we only got working two release
ago is really annoying. I'd suggest reverting the commit for now, or
at least making it an optional config option.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: kernel after 5.0-rc2 may not boot using BBL
2019-02-08 8:32 ` Christoph Hellwig
@ 2019-02-08 9:02 ` Anup Patel
2019-02-08 9:13 ` Christoph Hellwig
0 siblings, 1 reply; 12+ messages in thread
From: Anup Patel @ 2019-02-08 9:02 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Atish Patra, linux-riscv, Anup Patel, Andreas Schwab
On Fri, Feb 8, 2019 at 2:02 PM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Thu, Feb 07, 2019 at 10:08:14PM -0800, Atish Patra wrote:
> > If you are building a larger kernel image, it may not boot using BBL after
> > 5.0-rc2. It works fine with OpenSBI though.
> >
> > Here is the reasoning in case anybody else is facing the same issue.
> >
> > The following patch was added 5.0-rc2 which helps reduce the flat image size
> > for Linux kernel.
> >
> > "22e6a2e1 RISC-V: Make BSS section as the last section in vmlinux.lds.S"
> >
> > As the BSS section is moved to the end of the ELF, flat image will not
> > include it. As BBL copies the DTB at the next 2MB page boundary, BSS
> > section may overlap with DTB address. Kernel clears BSS section during early
> > boot which may clear the DTB as well leading to a boot failure.
>
> Breaking everyones (qemu) setups that we only got working two release
> ago is really annoying. I'd suggest reverting the commit for now, or
> at least making it an optional config option.
It is a bug in BBL because it is not keeping sufficient gap between
Linux kernel end and DTB. The change pointed by Atish actually
reduced flat kernel binary size by almost 1MB.
Rather than:
1. First revert in Linux
2. Fix in BBL
3. Bring back in Linux
I would suggest just do:
1. Fix in BBL
Here's my BBL pull request:
https://github.com/riscv/riscv-pk/pull/144
Regards,
Anup
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: kernel after 5.0-rc2 may not boot using BBL
2019-02-08 9:02 ` Anup Patel
@ 2019-02-08 9:13 ` Christoph Hellwig
2019-02-08 9:17 ` Anup Patel
0 siblings, 1 reply; 12+ messages in thread
From: Christoph Hellwig @ 2019-02-08 9:13 UTC (permalink / raw)
To: Anup Patel
Cc: Christoph Hellwig, Atish Patra, linux-riscv, Anup Patel, Andreas Schwab
On Fri, Feb 08, 2019 at 02:32:51PM +0530, Anup Patel wrote:
> It is a bug in BBL because it is not keeping sufficient gap between
> Linux kernel end and DTB. The change pointed by Atish actually
> reduced flat kernel binary size by almost 1MB.
And that is all great. But it breaks peoples few existing RISC-V
setups, which is the best way to frustate every single of the few
users out there. And that is best way to lose any interested in this
already hard to use mess.
> Here's my BBL pull request:
> https://github.com/riscv/riscv-pk/pull/144
And that isn't going to help anyone who doesn't want to update every
single fragile piece of crap involved in booting RISC-V every day..
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: kernel after 5.0-rc2 may not boot using BBL
2019-02-08 9:13 ` Christoph Hellwig
@ 2019-02-08 9:17 ` Anup Patel
2019-02-08 17:28 ` Palmer Dabbelt
0 siblings, 1 reply; 12+ messages in thread
From: Anup Patel @ 2019-02-08 9:17 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Atish Patra, linux-riscv, Anup Patel, Andreas Schwab
On Fri, Feb 8, 2019 at 2:43 PM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Fri, Feb 08, 2019 at 02:32:51PM +0530, Anup Patel wrote:
> > It is a bug in BBL because it is not keeping sufficient gap between
> > Linux kernel end and DTB. The change pointed by Atish actually
> > reduced flat kernel binary size by almost 1MB.
>
> And that is all great. But it breaks peoples few existing RISC-V
> setups, which is the best way to frustate every single of the few
> users out there. And that is best way to lose any interested in this
> already hard to use mess.
There is no issue if you are building Linux RISC-V defconfig.
The issue starts manifesting only if you more drivers enabled.
Again, with growing kernel not everyone will see this issue because
it will only show-up only when gap between payload_end and next
2MB aligned address is not sufficient to cover BSS section.
Regards,
Anup
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: kernel after 5.0-rc2 may not boot using BBL
2019-02-08 9:17 ` Anup Patel
@ 2019-02-08 17:28 ` Palmer Dabbelt
2019-02-09 3:30 ` Anup Patel
0 siblings, 1 reply; 12+ messages in thread
From: Palmer Dabbelt @ 2019-02-08 17:28 UTC (permalink / raw)
To: atish.patra, anup
Cc: Christoph Hellwig, atish.patra, linux-riscv, Anup.Patel, schwab
On Fri, 08 Feb 2019 01:17:00 PST (-0800), anup@brainfault.org wrote:
> On Fri, Feb 8, 2019 at 2:43 PM Christoph Hellwig <hch@infradead.org> wrote:
>>
>> On Fri, Feb 08, 2019 at 02:32:51PM +0530, Anup Patel wrote:
>> > It is a bug in BBL because it is not keeping sufficient gap between
>> > Linux kernel end and DTB. The change pointed by Atish actually
>> > reduced flat kernel binary size by almost 1MB.
>>
>> And that is all great. But it breaks peoples few existing RISC-V
>> setups, which is the best way to frustate every single of the few
>> users out there. And that is best way to lose any interested in this
>> already hard to use mess.
>
> There is no issue if you are building Linux RISC-V defconfig.
>
> The issue starts manifesting only if you more drivers enabled.
> Again, with growing kernel not everyone will see this issue because
> it will only show-up only when gap between payload_end and next
> 2MB aligned address is not sufficient to cover BSS section.
I agree with Christoph here: we should revert the commit. There are various
versions of BBL floating around that are a big headache to update, and since
all the patch in question does is reduce the flat image size it's not worth
breaking existing setups.
I also don't like the proposed fix, as that just statically sizes a 16MiB BSS.
While that's fairly large, it is in essence just kicking the can down the road.
The kernel on my laptop has a 7MiB BSS, and it's just an arbitrary smattering
of the drivers I happen to use. I'm not sure what the right long-term solution
is here. I kind of want to say "just use an ELF", as someone has already sat
down and figured out how to put everything into a file that's required to make
a binary run. I feel like doing anything else here is really just going to
involve re-inventing the wheel.
That's a bigger discussion, I've sent out the revert and will include it next
week unless someone has an objection.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: kernel after 5.0-rc2 may not boot using BBL
2019-02-08 17:28 ` Palmer Dabbelt
@ 2019-02-09 3:30 ` Anup Patel
2019-02-11 8:25 ` Christoph Hellwig
0 siblings, 1 reply; 12+ messages in thread
From: Anup Patel @ 2019-02-09 3:30 UTC (permalink / raw)
To: Palmer Dabbelt
Cc: Christoph Hellwig, Atish Patra, linux-riscv, Anup Patel, Andreas Schwab
On Fri, Feb 8, 2019 at 10:59 PM Palmer Dabbelt <palmer@sifive.com> wrote:
>
> On Fri, 08 Feb 2019 01:17:00 PST (-0800), anup@brainfault.org wrote:
> > On Fri, Feb 8, 2019 at 2:43 PM Christoph Hellwig <hch@infradead.org> wrote:
> >>
> >> On Fri, Feb 08, 2019 at 02:32:51PM +0530, Anup Patel wrote:
> >> > It is a bug in BBL because it is not keeping sufficient gap between
> >> > Linux kernel end and DTB. The change pointed by Atish actually
> >> > reduced flat kernel binary size by almost 1MB.
> >>
> >> And that is all great. But it breaks peoples few existing RISC-V
> >> setups, which is the best way to frustate every single of the few
> >> users out there. And that is best way to lose any interested in this
> >> already hard to use mess.
> >
> > There is no issue if you are building Linux RISC-V defconfig.
> >
> > The issue starts manifesting only if you more drivers enabled.
> > Again, with growing kernel not everyone will see this issue because
> > it will only show-up only when gap between payload_end and next
> > 2MB aligned address is not sufficient to cover BSS section.
>
> I agree with Christoph here: we should revert the commit. There are various
> versions of BBL floating around that are a big headache to update, and since
> all the patch in question does is reduce the flat image size it's not worth
> breaking existing setups.
>
> I also don't like the proposed fix, as that just statically sizes a 16MiB BSS.
> While that's fairly large, it is in essence just kicking the can down the road.
> The kernel on my laptop has a 7MiB BSS, and it's just an arbitrary smattering
> of the drivers I happen to use. I'm not sure what the right long-term solution
> is here. I kind of want to say "just use an ELF", as someone has already sat
> down and figured out how to put everything into a file that's required to make
> a binary run. I feel like doing anything else here is really just going to
> involve re-inventing the wheel.
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.
Regards,
Anup
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: kernel after 5.0-rc2 may not boot using BBL
2019-02-09 3:30 ` Anup Patel
@ 2019-02-11 8:25 ` Christoph Hellwig
2019-02-11 8:45 ` Anup Patel
2019-02-11 19:54 ` Palmer Dabbelt
0 siblings, 2 replies; 12+ messages in thread
From: Christoph Hellwig @ 2019-02-11 8:25 UTC (permalink / raw)
To: Anup Patel
Cc: Anup Patel, Andreas Schwab, Palmer Dabbelt, Christoph Hellwig,
Atish Patra, linux-riscv
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..
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: kernel after 5.0-rc2 may not boot using BBL
2019-02-11 8:25 ` Christoph Hellwig
@ 2019-02-11 8:45 ` Anup Patel
2019-02-12 1:24 ` Michael Clark
2019-02-11 19:54 ` Palmer Dabbelt
1 sibling, 1 reply; 12+ messages in thread
From: Anup Patel @ 2019-02-11 8:45 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Anup Patel, Atish Patra, linux-riscv, Palmer Dabbelt, Andreas Schwab
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..
The kernel breakage totally unintentional. I had done all testing using BBL
and OpenSBI with Linux compiled using defconfig but never saw the issue.
Regards,
Anup
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: kernel after 5.0-rc2 may not boot using BBL
2019-02-11 8:25 ` Christoph Hellwig
2019-02-11 8:45 ` Anup Patel
@ 2019-02-11 19:54 ` Palmer Dabbelt
1 sibling, 0 replies; 12+ messages in thread
From: Palmer Dabbelt @ 2019-02-11 19:54 UTC (permalink / raw)
To: Christoph Hellwig
Cc: anup, Anup.Patel, Christoph Hellwig, atish.patra, schwab, linux-riscv
On Mon, 11 Feb 2019 00:25:06 PST (-0800), Christoph Hellwig 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..
I agree. I don't think anyone wants to move away from BBL more than I do, and
while the OpenSBI+u-boot stuff is progressing well we can't just instantly
deprecate every other boot flow -- particularly not the one that I use :).
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: kernel after 5.0-rc2 may not boot using BBL
2019-02-11 8:45 ` Anup Patel
@ 2019-02-12 1:24 ` Michael Clark
2019-02-13 21:00 ` Palmer Dabbelt
0 siblings, 1 reply; 12+ messages in thread
From: Michael Clark @ 2019-02-12 1:24 UTC (permalink / raw)
To: Anup Patel, Christoph Hellwig
Cc: Atish Patra, linux-riscv, Anup Patel, Palmer Dabbelt, Andreas Schwab
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.
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
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.
--
Trust without verification is corruption
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: kernel after 5.0-rc2 may not boot using BBL
2019-02-12 1:24 ` Michael Clark
@ 2019-02-13 21:00 ` Palmer Dabbelt
0 siblings, 0 replies; 12+ messages in thread
From: Palmer Dabbelt @ 2019-02-13 21:00 UTC (permalink / raw)
To: Michael Clark
Cc: anup, Anup Patel, Christoph Hellwig, atish.patra, schwab, linux-riscv
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-02-13 21:00 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-08 6:08 kernel after 5.0-rc2 may not boot using BBL Atish Patra
2019-02-08 8:32 ` Christoph Hellwig
2019-02-08 9:02 ` Anup Patel
2019-02-08 9:13 ` Christoph Hellwig
2019-02-08 9:17 ` Anup Patel
2019-02-08 17:28 ` Palmer Dabbelt
2019-02-09 3:30 ` Anup Patel
2019-02-11 8:25 ` Christoph Hellwig
2019-02-11 8:45 ` Anup Patel
2019-02-12 1:24 ` Michael Clark
2019-02-13 21:00 ` Palmer Dabbelt
2019-02-11 19:54 ` Palmer Dabbelt
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).