INVESTMAX. Защитим и приумножим. Пароль: выжига

[Annette Perez]

FAQ внутри.

good2263411.pdf
Description: Adobe PDF document

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Florian Weimer]

* Riku Voipio:

> On Thu, Jun 28, 2018 at 08:11:14PM +0200, Florian Weimer wrote:
>> * Niels Thykier:
>> 
>> > armel/armhf:
>> > 
>> >
>> >  * Undesirable to keep the hardware running beyond 2020.  armhf VM
>> >support uncertain. (DSA)
>> >- Source: [DSA Sprint report]
>> 
>> Fedora is facing an issue running armhf under virtualization on arm64:
>> 
>>   
>
> I think you mean:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1576593

Yes, that's right, I copy-pasted the wrong bug URL.  It's filed as a
Red Hat Enterprise Linux bug because the Fedora builders run Fedora
VMs on that platform.

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Lennart Sorensen]

On Fri, Jun 29, 2018 at 10:20:50AM +0100, Luke Kenneth Casson Leighton wrote:
>  in addition, arm64 is usually speculative OoO (Cavium ThunderX V1
> being a notable exception) which means it's vulnerable to spectre and
> meltdown attacks, whereas 32-bit ARM is exclusively in-order.  if you
> want to GUARANTEE that you've got spectre-immune hardware you need
> either any 32-bit system (where even Cortex A7 has virtualisattion) or
> if 64-bit is absolutely required use Cortex A53.

The Cortex A8, A7 and A5 are in order.  The A9, A15, A17 etc are out of
order execution.  So any 32 bit arm worth using is pretty much always
out of order execution.

For 64 bit, I think the A35 and A53 are in order while the A57, A72 etc
are out of order.

Of course non Cortex designs vary (I think Marvel's JP4 core was out of
order execution for example).

After all, in general in order execution equals awful performance.

-- 
Len Sorensen

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Luke Kenneth Casson Leighton]

On Fri, Jun 29, 2018 at 12:50 PM, Julien Cristau  wrote:

> Everyone, please avoid followups to debian-po...@lists.debian.org.
> Unless something is relevant to *all* architectures (hint: discussion of
> riscv or arm issues don't qualify), keep replies to the appropriate
> port-specific mailing list.

 apologies, julien: as an outsider i'm not completely familiar with
the guidelines.  the reduction in memory-usage at the linker phase
"-Wl,--no-keep-memory" however - and the associated inherent
slowly-inexorably-increasing size is i feel definitely something that
affects all ports.

 it is really *really* tricky to get any kind of traction *at all*
with people on this.  it's not gcc's problem to solve, it's not one
package's problem to solve, it's not any one distros problem to solve,
it's not any one port's problem to solve and so on, *and* it's a
slow-burn problem that's taking *literally* a decade to become more
and more of a problem.  consequently getting reports and feedback to
the binutils team is... damn hard.

l.

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Julien Cristau]

On 06/27/2018 10:03 PM, Niels Thykier wrote:
> Hi,
> 
> 
> As part of the interim architecture qualification for buster, we request
> that DSA, the security team and the toolchain maintainers review and
> update their list of known concerns for buster release architectures.
> 
Everyone, please avoid followups to debian-po...@lists.debian.org.
Unless something is relevant to *all* architectures (hint: discussion of
riscv or arm issues don't qualify), keep replies to the appropriate
port-specific mailing list.

Thanks,
Julien

Re: Arch qualification for buster: call for DSA, Security, toolchain concernsj

[Luke Kenneth Casson Leighton]

On Fri, Jun 29, 2018 at 12:06 PM, John Paul Adrian Glaubitz
 wrote:
> On 06/29/2018 10:41 AM, Luke Kenneth Casson Leighton wrote:
>> On Fri, Jun 29, 2018 at 8:16 AM, Uwe Kleine-König  
>> wrote:
>>
 In short, the hardware (development boards) we're currently using to
 build armel and armhf packages aren't up to our standards, and we
 really, really want them to go away when stretch goes EOL (expected in
 2020).  We urge arm porters to find a way to build armhf packages in
 VMs or chroots on server-class arm64 hardware.
>>
>>  from what i gather the rule is that the packages have to be built
>> native.  is that a correct understanding or has the policy changed?
>
> Native in the sense that the CPU itself is not emulated which is the case
> when building arm32 packages on arm64.

 ok.  that's clear.  thanks john.

> I think that building on arm64 after fixing the bug in question is the
> way to move forward. I'm surprised the bug itself hasn't been fixed yet,
> doesn't speak for ARM.

 if you mean ARM hardware (OoO), it's too late.  systems are out there
with OoO speculative execution bugs in the hardware (and certainly
more to be found), and they're here to stay unfortunately.

 if you mean that buildd on 32-bit systems could be modified to pass
"-Wl,--no-keep-memory" to all linker phases to see if that results in
the anticipated dramatic reduction in memory usage, that's
straightforward to try, nothing to do with ARM themselves.

l.

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Luke Kenneth Casson Leighton]

On Fri, Jun 29, 2018 at 12:23 PM, Adam D. Barratt
 wrote:

>>  i don't know: i'm an outsider who doesn't have the information in
>> short-term memory, which is why i cc'd the debian-riscv team as they
>> have current facts and knowledge foremost in their minds.  which is
>> why i included them.
>
> It would have been wiser to do so *before* stating that nothing was
> happening as if it were a fact.

 true... apologies.

>>  ah.  so what you're saying is, you could really do with some extra
>> help?
>
> I don't think that's ever been in dispute for basically any core team
> in Debian.

 :)

> That doesn't change the fact that the atmosphere around the change in
> question has made me feel very uncomfortable and unenthused about SRM
> work. (I realise that this is somewhat of a self-feeding energy
> monster.)

 i hear ya.

l.

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Adam D. Barratt]

On Fri, 2018-06-29 at 11:44 +0100, Luke Kenneth Casson Leighton wrote:
[...]
> On Fri, Jun 29, 2018 at 10:35 AM, Adam D. Barratt
>  wrote:
> 
> > >  what is the reason why that package is not moving forward?
> > 
> > I assume you're referring to the dpkg upload that's in proposed-
> > updates
> > waiting for the point release in two weeks time?
> 
>  i don't know: i'm an outsider who doesn't have the information in
> short-term memory, which is why i cc'd the debian-riscv team as they
> have current facts and knowledge foremost in their minds.  which is
> why i included them.

It would have been wiser to do so *before* stating that nothing was
happening as if it were a fact.

> > I'm also getting very tired of the repeated vilification of SRM
> > over
> > this, and if there were any doubt can assure you that it is not
> > increasing at least my inclination to spend my already limited free
> > time on Debian activity.
> 
>  ah.  so what you're saying is, you could really do with some extra
> help?

I don't think that's ever been in dispute for basically any core team
in Debian.

That doesn't change the fact that the atmosphere around the change in
question has made me feel very uncomfortable and unenthused about SRM
work. (I realise that this is somewhat of a self-feeding energy
monster.)

Regards,

Adam

Re: Arch qualification for buster: call for DSA, Security, toolchain concernsj

[John Paul Adrian Glaubitz]

On 06/29/2018 10:41 AM, Luke Kenneth Casson Leighton wrote:
> On Fri, Jun 29, 2018 at 8:16 AM, Uwe Kleine-König  
> wrote:
> 
>>> In short, the hardware (development boards) we're currently using to
>>> build armel and armhf packages aren't up to our standards, and we
>>> really, really want them to go away when stretch goes EOL (expected in
>>> 2020).  We urge arm porters to find a way to build armhf packages in
>>> VMs or chroots on server-class arm64 hardware.
> 
>  from what i gather the rule is that the packages have to be built
> native.  is that a correct understanding or has the policy changed?

Native in the sense that the CPU itself is not emulated which is the case
when building arm32 packages on arm64. We're also building i386 packages
on amd64 and we used to build powerpc packages on ppc64 (and we will continue
to do that once the move of powerpc to ports has been completed).

I think that building on arm64 after fixing the bug in question is the
way to move forward. I'm surprised the bug itself hasn't been fixed yet,
doesn't speak for ARM.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Fri, Jun 29, 2018 at 10:35 AM, Adam D. Barratt
 wrote:

>>  what is the reason why that package is not moving forward?
>
> I assume you're referring to the dpkg upload that's in proposed-updates
> waiting for the point release in two weeks time?

 i don't know: i'm an outsider who doesn't have the information in
short-term memory, which is why i cc'd the debian-riscv team as they
have current facts and knowledge foremost in their minds.  which is
why i included them.

> I'm also getting very tired of the repeated vilification of SRM over
> this, and if there were any doubt can assure you that it is not
> increasing at least my inclination to spend my already limited free
> time on Debian activity.

 ah.  so what you're saying is, you could really do with some extra help?

l.

armel/armhf arch qualification for buster: call for DSA, Security, toolchain concernsj

[W. Martin Borgert]

Quoting Uwe Kleine-König :

If the concerns are mostly about the hardware not being rackable, there
is a rackable NAS by Netgear:


https://www.netgear.com/business/products/storage/readynas/RN2120.aspx#tab-techspecs


This seems to be out of stock and discontinued, unfortunately.

Anyway, I'm relatively sure, that I can convince my boss to sponsor/donate
both armel and armhf hardware for Debian, if that is of any help. Or arm64
used in "32 bits mode".

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Adam D. Barratt]

On Fri, 2018-06-29 at 10:20 +0100, Luke Kenneth Casson Leighton wrote:
[...]
>  debian-riscv has been repeatedly asking for a single zero-impact
> line
> to be included in *one* file in *one* dpkg-related package which
> would
> allow riscv to stop being a NMU architecture and become part of
> debian/unstable (and quickly beyond), for at least six months, now.
> cc'ing the debian-riscv list because they will know the details about
> this.  it's really quite ridiculous that a single one-line change
> having absolutely no effect on any other architecture whatsover is
> not
> being actioned and is holding debian-riscv back because of that.
> 
>  what is the reason why that package is not moving forward?

I assume you're referring to the dpkg upload that's in proposed-updates 
waiting for the point release in two weeks time? Please check your
facts before ranting, particularly with such a wide cross-posting.

Also, ttbomk, the dpkg change landing in stable is not likely to
magically lead to the architecture being added to unstable - a decision
which is not the release team's to make or block. Again, please ensure
you've actually done your research.

I'm also getting very tired of the repeated vilification of SRM over
this, and if there were any doubt can assure you that it is not
increasing at least my inclination to spend my already limited free
time on Debian activity.

Regards,

Adam

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Luke Kenneth Casson Leighton]

On Wed, Jun 27, 2018 at 9:03 PM, Niels Thykier  wrote:

> armel/armhf:
> 
>
>  * Undesirable to keep the hardware running beyond 2020.  armhf VM
>support uncertain. (DSA)
>- Source: [DSA Sprint report]

 [other affected 32-bit architectures removed but still relevant]

 ... i'm not sure how to put this other than to just ask the question.
has it occurred to anyone to think through the consequences of not
maintaining 32-bit versions of debian for the various different
architectures?  there are literally millions of ARM-based tablets and
embedded systems out there which will basically end up in landfill if
a major distro such as debian does not take a stand and push back
against the "well everything's going 64-bit so why should *we*
bother?" meme.

 arm64 is particularly inefficient and problematic compared to
aarch32: the change in the instruction set resulted in dropping some
of the more efficiently-encoded instructions that extend a 64-bit
program size, require a whopping FIFTY PERCENT instruction-cache size
increase to compensate for, whch increased power consumption by over
15%.

 in addition, arm64 is usually speculative OoO (Cavium ThunderX V1
being a notable exception) which means it's vulnerable to spectre and
meltdown attacks, whereas 32-bit ARM is exclusively in-order.  if you
want to GUARANTEE that you've got spectre-immune hardware you need
either any 32-bit system (where even Cortex A7 has virtualisattion) or
if 64-bit is absolutely required use Cortex A53.

 basically, abandoning or planning to abandon 32-bit ARM *right now*
leaves security-conscious end-users in a really *really* dicey
position.


> We are currently unaware of any new architectures likely to be ready in
> time for inclusion in buster.

 debian-riscv has been repeatedly asking for a single zero-impact line
to be included in *one* file in *one* dpkg-related package which would
allow riscv to stop being a NMU architecture and become part of
debian/unstable (and quickly beyond), for at least six months, now.
cc'ing the debian-riscv list because they will know the details about
this.  it's really quite ridiculous that a single one-line change
having absolutely no effect on any other architecture whatsover is not
being actioned and is holding debian-riscv back because of that.

 what is the reason why that package is not moving forward?

 l.

Re: Arch qualification for buster: call for DSA, Security, toolchain concernsj

[Luke Kenneth Casson Leighton]

On Fri, Jun 29, 2018 at 8:16 AM, Uwe Kleine-König  
wrote:

> Hello,
>
> On Wed, Jun 27, 2018 at 08:03:00PM +, Niels Thykier wrote:
>> armel/armhf:
>> 
>>
>>  * Undesirable to keep the hardware running beyond 2020.  armhf VM
>>support uncertain. (DSA)
>>- Source: [DSA Sprint report]
>>
>> [DSA Sprint report]:
>> https://lists.debian.org/debian-project/2018/02/msg4.html
>
> In this report Julien Cristau wrote:
>
>> In short, the hardware (development boards) we're currently using to
>> build armel and armhf packages aren't up to our standards, and we
>> really, really want them to go away when stretch goes EOL (expected in
>> 2020).  We urge arm porters to find a way to build armhf packages in
>> VMs or chroots on server-class arm64 hardware.

 from what i gather the rule is that the packages have to be built
native.  is that a correct understanding or has the policy changed?

>
> If the concerns are mostly about the hardware not being rackable, there
> is a rackable NAS by Netgear:
>
> 
> https://www.netgear.com/business/products/storage/readynas/RN2120.aspx#tab-techspecs
>
> with an armhf cpu. Not sure if cpu speed (1.2 GHz) and available RAM (2
> GiB) are good enough.

 no matter how much RAM there is it's never going to be "enough", and
letting systems go into swap is also not a viable option [2]

 i've been endeavouring to communicate the issue for many many years
wrt building (linking) of very large packages, for a long, *long*
time.  as it's a strategic cross-distro problem that's been very very
slowly creeping up on *all* distros as packages inexorably creep up in
size, reaching people about the problem and possible solutions is
extremely difficult.  eventually i raised a bug on binutils and it
took several months to communicate the extent and scope of the problem
even to the developer of binutils:

 https://sourceware.org/bugzilla/show_bug.cgi?id=22831

the problem is that ld from binutils by default, unlike gcc which
looks dynamically at how much RAM is available, loads absolutely all
object files into memory and ASSUMES that swap space is going to take
care of any RAM deficiencies.

 unfortunately due to the amount of cross-referencing that takes place
in the linker phase this "strategy" causes MASSIVE thrashing, even if
one single object file is sufficient to cause swapping.

 this is particularly pertinent for systems which compile with debug
info switched on as it is far more likely that a debug compile will go
into swap, due to the amount of RAM being consumed.

 firefox now requires 7GB of resident RAM, making it impossible to
compile on 32-bit systems  webkit-based packages require well over 2GB
RAM (and have done for many years).  i saw one scientific package a
couple years back that could not be compiled for 32-bit systems
either.

 all of this is NOT the fault of the PACKAGES [1], it's down to the
fact that *binutils* - ld's default memory-allocation strategy - is
far too aggressive.

 the main developer of ld has this to say:

Please try if "-Wl,--no-keep-memory" works.

 now, that's *not* a good long-term "solution" - it's a drastic,
drastic hack that cuts the optimisation of keeping object files in
memory stone dead.  it'll work... it will almost certainly result in
32-bit systems being able to successfully link applications that
previously failed... but it *is* a hack.  someone really *really*
needs to work with the binutils developer to *properly* solve this.

 if any package maintainer manages to use the above hack to
successfully compile 32-bit packages that previously completely ran
out of RAM or otherwise took days to complete, please do put a comment
to that effect in the binutiols bugreport, it will help everyone in
the entire GNU/Linux community to do so.

l.

[1] really, it is... developers could easily split packages into
dynamic-loadable modules, where each module easily compiles well below
even 2GB or 1GB of RAM.  they choose not to, choosing instead to link
hundreds of object files into a single executable (or library).
asking so many developers to change their strategy however... yyeah :)
 big task, i ain't taking responsibility for that one.

[2] the amount of memory being required for the linker phase of large
packages over time goes up, and up, and up, and up... when is it going
to stop?  never.  so just adding more RAM is never going to "solve"
the problem, is it?  it just *avoids* the problem.  letting even
64-bit systems go into swap is a huge waste of resources as builds
that go into swap will consume far more resources and time.  so *even
on 64-bit systems* this needs solving.

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Riku Voipio]

On Thu, Jun 28, 2018 at 08:11:14PM +0200, Florian Weimer wrote:
> * Niels Thykier:
> 
> > armel/armhf:
> > 
> >
> >  * Undesirable to keep the hardware running beyond 2020.  armhf VM
> >support uncertain. (DSA)
> >- Source: [DSA Sprint report]
> 
> Fedora is facing an issue running armhf under virtualization on arm64:
> 
>   

I think you mean:

https://bugzilla.redhat.com/show_bug.cgi?id=1576593

>   
> 
> Unless the discussion has moved somewhere where I can't follow it, no
> one seems to have solid idea what is going on. 

True. Looking at comment #22, the suggestion seems to be that the guest is
doing something wrong, and kvm is being terrible at pinpointing the source.

> It's also not clear that this configuration has substantial vendor or
> community support. This makes me concerned that virtualization is a viable
> path forward here.

I understand your concern. It would be surprising if this specific bug doesn't
get found and fixed. It's probably stuck because everyone thinks it's 
probably someone elses bug ;)

I still think the armhf vm on arm64 is the only reasonable path forward medium
term. The existing arm64 hw that suport arm32 vm's is still around and
infinitely better than native aarch32 builder hw, and should still be viable
for some time. 

Riku

Re: Arch qualification for buster: call for DSA, Security, toolchain concernsj

[Uwe Kleine-König]

Hello,

On Wed, Jun 27, 2018 at 08:03:00PM +, Niels Thykier wrote:
> armel/armhf:
> 
> 
>  * Undesirable to keep the hardware running beyond 2020.  armhf VM
>support uncertain. (DSA)
>- Source: [DSA Sprint report]
> 
> [DSA Sprint report]:
> https://lists.debian.org/debian-project/2018/02/msg4.html

In this report Julien Cristau wrote:

> In short, the hardware (development boards) we're currently using to
> build armel and armhf packages aren't up to our standards, and we
> really, really want them to go away when stretch goes EOL (expected in
> 2020).  We urge arm porters to find a way to build armhf packages in
> VMs or chroots on server-class arm64 hardware.

If the concerns are mostly about the hardware not being rackable, there
is a rackable NAS by Netgear:


https://www.netgear.com/business/products/storage/readynas/RN2120.aspx#tab-techspecs

with an armhf cpu. Not sure if cpu speed (1.2 GHz) and available RAM (2
GiB) are good enough. The machine can run mainline Linux[1]. I think
U-Boot doesn't support this machine in mainline though.

Apart from that the people in #debian-arm (e.g. Sledge) seem to be
positive that at least armhf should be fine to be built on arm64
hardware.

Best regards
Uwe

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts


signature.asc
Description: PGP signature