Am Do., 19. Nov. 2020 um 18:32 Uhr schrieb Peter Stuge :
> Patrick Georgi via coreboot wrote:
> > > My argument is solely on complexity, but please don't trust that hash
> too
> > > much.
> >
> > If I shouldn't trust
> > "16 commit 4c523ed10f25de872ac0513ebd6ca53d3970b9de vboot" too much,
> >
Patrick Georgi via coreboot wrote:
> > My argument is solely on complexity, but please don't trust that hash too
> > much.
>
> If I shouldn't trust
> "16 commit 4c523ed10f25de872ac0513ebd6ca53d3970b9de vboot" too much,
> why should I trust
> "04 tree 4c523ed10f25de872ac0513ebd6ca53d3970b9d
On 18.11.20 23:53, Julius Werner wrote:
> (Also, while we're on the subject of submodules causing pain, Nico...
> whenever I want to build test older Intel generations I have to first
> figure out again which of them don't rely on libgfxinit, or how to
> hack around in their Kconfigs to disable it,
Am Do., 19. Nov. 2020 um 01:26 Uhr schrieb Peter Stuge :
> > the Git SHA of the submodule HEAD is stored in the main coreboot repo.
>
> My argument is solely on complexity, but please don't trust that hash too
> much.
>
If I shouldn't trust
"16 commit 4c523ed10f25de872ac0513ebd6ca53d3970b9de v
> > > Having an undocumented (or silently installed, therefore unexpected)
> > > dependency is undesirable (especially for a firmware), no question
> > > about that.
> >
> > Sorry, I still get the impression that there is a fundamental
> > misunderstanding about what Git submodules are here.
>
> I
Julius Werner wrote:
> > Having an undocumented (or silently installed, therefore unexpected)
> > dependency is undesirable (especially for a firmware), no question
> > about that.
>
> Sorry, I still get the impression that there is a fundamental
> misunderstanding about what Git submodules are he
Am Mi., 18. Nov. 2020 um 23:54 Uhr schrieb Julius Werner <
jwer...@chromium.org>:
> because unlike everything
> else you need to build coreboot there seems to be no way to get an ADA
> toolchain from crossgcc.
gnat (gcc's Ada implementation) needs an Ada implementation to bootstrap
(just like gcc
> Having an undocumented (or silently installed, therefore unexpected)
> dependency is undesirable (especially for a firmware), no question about that.
Sorry, I still get the impression that there is a fundamental
misunderstanding about what Git submodules are here. It's *just*
source code! It's
Hi Julius,
On 12.11.20 03:29, Julius Werner wrote:
> So I think the "official" rule is basically that the minimum
> requirement for host utilities is the same compiler and version that
> crossgcc uses, which I think makes some amount of sense (otherwise
> we'll just have to keep tracking and deplo
Hi all,
On 12.11.20 03:29, Julius Werner wrote:
> I don't think it's fair to single in on vboot as the big problem here.
it's not by any definition but, FWIW, it became one in practice. I don't
think it's because of GCC versions or anything that we should try to fix
by testing. One big difference
Am Mi., 18. Nov. 2020 um 09:14 Uhr schrieb David Hendricks <
david.hendri...@gmail.com>:
> or is the problem here just the fact that the hashing library is part of a
> submodule?
>
If it's the submodule that is in question here, we _could_ import vboot as
a subtree (and compatibly, too!), although
>
> > You seem to imply that this may cause some kind of security or
> availability problem
>
> Can you guarantee that a silently installed submodule's repo won't get
> hacked and replaced with malicious code for example? We have seen that
> happening with other repos already (github, sourceforge a
Well, this seems to be really going off topic. My only intention was
to ask what the required/recommended host(system) compiler was and
what documentation there was for that.
Branden Waldner wrote:
> Is there an expected minimal system gcc version and if so, is it
> documented? I couldn't find it
Hi,
If I may express my thoughts on this...
> Yeah, I really don't understand your concern here.
Having an undocumented (or silently installed, therefore unexpected)
dependency is undesirable (especially for a firmware), no question
about that.
> You seem to imply that this may cause some kind
> One is what you describe - a generic utility supporting everything
> that gets installed into say /usr/local/bin for lots of different
> invocations to do lots of different things with lots of different
> coreboot images.
>
> Two is specifically what is required to complete the configured build.
Am Di., 17. Nov. 2020 um 05:06 Uhr schrieb Peter Stuge :
> It's absurd to me that coreboot would require any routines out of any
> submodule for a build which will not use those routines.
coreboot doesn't, cbfstool does.
One purpose of Kconfig is to ensure that only what's neccessary gets built.
Julius Werner wrote:
> > > needed in cbfstool (e.g. for the --hash-algorithm parameter to add a
> > > hash attribute to a file), and there is no Kconfig cbfstool so you
> > > can't just configure it out if you don't need it.
> >
> > It is clear that I don't need that functionality when I build a
>
> > vboot is used for more than just boot verification these days, we use
> > it as a sort of generic crypto toolbox for all of coreboot's crypto
> > needs (because it wouldn't make sense to implement, say, SHA-256
> > algorithms twice). For host utilities in particular, some of these are
> > neede
Julius,
Julius Werner wrote:
> >> Whenever I want a build without vboot I get really annoyed about this
> >> hardcoded dependency, even when vboot is disabled in Kconfig.
> >>
> >> Would a patch to make the dependency conditional on Kconfig get accepted?
> >
> > I should hope so, though I recommen
>> Whenever I want a build without vboot I get really annoyed about this
>> hardcoded dependency, even when vboot is disabled in Kconfig.
>>
>> Would a patch to make the dependency conditional on Kconfig get accepted?
>
> I should hope so, though I recommend starting a new thread to see if experts
On Mon, Nov 9, 2020 at 4:51 PM Peter Stuge wrote:
> Nico Huber wrote:
> > I don't think it's documented. As you already noticed, we depend on
> > a 3rdparty library (vboot), so we actually don't know the minimum.
>
> Whenever I want a build without vboot I get really annoyed about this
> hardcode
Nico Huber wrote:
> I don't think it's documented. As you already noticed, we depend on
> a 3rdparty library (vboot), so we actually don't know the minimum.
Whenever I want a build without vboot I get really annoyed about this
hardcoded dependency, even when vboot is disabled in Kconfig.
Would a
On 10.11.20 00:38, Peter Stuge wrote:
> Branden Waldner wrote:
>> Is there an expected minimal system gcc version and if so, is it
>> documented? I couldn't find it noted anywhere.
I don't think it's documented. As you already noticed, we depend on
a 3rdparty library (vboot), so we actually don't
On Mon, Nov 9, 2020 at 5:38 PM Peter Stuge wrote:
> Branden Waldner wrote:
> > Is there an expected minimal system gcc version and if so, is it
> > documented? I couldn't find it noted anywhere.
>
> There's the crossgcc tool and make target to create a known-working
> toolchain for building coreb
Branden Waldner wrote:
> Is there an expected minimal system gcc version and if so, is it
> documented? I couldn't find it noted anywhere.
There's the crossgcc tool and make target to create a known-working
toolchain for building coreboot.
//Peter
___
25 matches
Mail list logo
