Recent

Author Topic: A (Debian) Quality Proposal  (Read 13859 times)

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: A (Debian) Quality Proposal
« Reply #30 on: January 21, 2022, 03:49:43 pm »
This has been a topic on the bug tracker as the same also results in problems on PPC64le. So these shouldn't be ignored, but will instead be fixed by themselves some time in the future once FPC generates correct static PIE binaries.

The explanation of that feature seems to indicate that GCC implemented features (more dynamic allocation of the register used for PIE (GOT pointer?)) to combat the performance degradation of PIE. that was what I was hinting at.

CHMCMD and fpdoc are quite performance sensitive. (though afaik they should be linked to libc, as they can use threading?)

added: I now realize that ppcx64 is in the log, so it is a 64-bit build where it probably hurts less. So probably this is about optimizations we don't yet do.
« Last Edit: January 21, 2022, 03:58:13 pm by marcov »

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: A (Debian) Quality Proposal
« Reply #31 on: January 21, 2022, 04:02:42 pm »
added: I now realize that ppcx64 is in the log, so it is a 64-bit build where it probably hurts less. So probably this is about optimizations we don't yet do.

It's not about optimizations, it's simply that you currently can't generate a working statically linked PIE binary with FPC. Thus FPC is build without PIE and thus hardening-no-pie is triggered by Lintian.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: A (Debian) Quality Proposal
« Reply #32 on: January 21, 2022, 04:15:21 pm »
It's not about optimizations, it's simply that you currently can't generate a working statically linked PIE binary with FPC. Thus FPC is build without PIE and thus hardening-no-pie is triggered by Lintian.

Yeah, but my point was that  if enabling PIE when it has a significant performance degradation might be a good reason to leave it disabled and flag it is as not hardening compatible. But I mostly had 32-bit in mind, which is of course worse than 64-bit from a performance impact (10% and more IIRC)

I now think those comments referred to dynamically allocating a 64-bit register for PIE supporting pointers using liveliness analysis, rather than reserving one outright.

dbannon

  • Hero Member
  • *****
  • Posts: 2786
    • tomboy-ng, a rewrite of the classic Tomboy
Re: A (Debian) Quality Proposal
« Reply #33 on: January 22, 2022, 01:19:34 pm »
I am still unsure how you want these things reported, bug report or but report and pull request. But I do know that they should not be reported here, in the forum. But thats what I am doing it until I know better.  :D

install/man/man5/fpc.cfg.5 contains developpers - spelling mistake

WRT the hardening issue, we can fix the immediate problem (if we wish) just by forcing the compiler to build a dynamically linked binary where it would other wise build a static one. But is it necessary ?  My thoughts are that if Debian need all binaries hardened then they can patch the build themselves ?

Hardening definitely make sense in a server or multiuser system, I am not so excited about it on a single use machine which probably makes up most of our compiler users. (Not end users, the compiler users.).

Apart from things in this particular post, I believe we have answers to original question, thanks !

Davo



Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: A (Debian) Quality Proposal
« Reply #34 on: January 22, 2022, 01:27:22 pm »
I am still unsure how you want these things reported, bug report or but report and pull request. But I do know that they should not be reported here, in the forum. But thats what I am doing it until I know better.  :D

Separate report and patch per "kind" of issues. IOW you can bundle if they are e.g. spelling errors in similar files.

You can also discuss and post patches or remarks here. Since many are mostly one line fixes, there is not much use for formality.

Quote
install/man/man5/fpc.cfg.5 contains developpers - spelling mistake

Fixed.

Quote
WRT the hardening issue, we can fix the immediate problem (if we wish) just by forcing the compiler to build a dynamically linked binary where it would other wise build a static one. But is it necessary ?  My thoughts are that if Debian need all binaries hardened then they can patch the build themselves ?

Well, Pascaldragon wants to keep it visible, though IMHO an override (so that it is still visible but no longer counted) is better.

Quote
Hardening definitely make sense in a server or multiuser system, I am not so excited about it on a single use machine which probably makes up most of our compiler users. (Not end users, the compiler users.).

Well, that is one of the problems of Linux, everything is in constant flux, and what was ok yesterday will be not today depending on the whimsy of a developer. There are no hard contracts of any kind, and when broken, usually the easiest way (only support the new) is taken.

It is one of the things that puts me off Linux.

« Last Edit: January 22, 2022, 01:28:59 pm by marcov »

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: A (Debian) Quality Proposal
« Reply #35 on: January 22, 2022, 02:46:28 pm »
Well, that is one of the problems of Linux, everything is in constant flux, and what was ok yesterday will be not today depending on the whimsy of a developer. There are no hard contracts of any kind, and when broken, usually the easiest way (only support the new) is taken.

Hence in part some of my rude comments about Debian yesterday: they rely on contributed packages which can change at the maintainer's whim, and once put in their repository they are most resistant to fixing stuff in the stable release... although some developers/maintainers are more successful than most.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

dbannon

  • Hero Member
  • *****
  • Posts: 2786
    • tomboy-ng, a rewrite of the classic Tomboy
Re: A (Debian) Quality Proposal
« Reply #36 on: January 23, 2022, 12:23:55 am »
Hence in part some of my rude comments about Debian yesterday: they rely on contributed packages which can change at the maintainer's whim, and once put in their repository they are most resistant to fixing stuff in the stable release... although some developers/maintainers are more successful than most.

We want a stable, predictable platform that does not change but does get absolutely every new feature that comes along.   ;)

Seriously, I think they get it right most of the time. The problem with Lazarus in Bullseye is a bad example but there are very many good examples. Their model of new packages into Sid, then testing and then after an indomitable wait, stable, is really the best you can hope for. Lazarus comes out twice a year, at any one time Testing will have a near current version but sooner or later they freeze it all and call it stable, then, that Lazarus is in Stable for two years. Two years is a long time in Lazarus speak. Only security or extreme functionally problems after that.

Ubuntu's long term release is also two years, same version of Lazarus in the first week of a LTR as the last week.

Otherwise its a rolling release model, massive changes every day, sigh, thats too scary for me !

Davo



Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

dbannon

  • Hero Member
  • *****
  • Posts: 2786
    • tomboy-ng, a rewrite of the classic Tomboy
Re: A (Debian) Quality Proposal
« Reply #37 on: January 23, 2022, 12:43:51 am »
Separate report and patch per "kind" of issues. IOW you can bundle if they are e.g. spelling errors in similar files.
You can also discuss and post patches or remarks here. Since many are mostly one line fixes, there is not much use for formality.
OK, understand. I think we have now covered everything we can reasonably expect from this end.

Quote
install/man/man5/fpc.cfg.5 contains developpers - spelling mistake - Fixed.
Thank you very much.

Quote
> WRT the hardening issue, ....
Well, Pascaldragon wants to keep it visible, though IMHO an override (so that it is still visible but no longer counted) is better.
As a problem for FPC, Hardening is more of an issue on PPC64el IMHO, being a server platform hardening is important. On Intel few user apps will be statically linked and even if they are, they can be forced not to be. No such option with PPC64el.
For my app in Debian I have just turned Hardening off for PPC64el and they accepted that. But no one is likely to be using it on PPC64el anyway !

Davo
Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: A (Debian) Quality Proposal
« Reply #38 on: January 23, 2022, 09:54:01 am »
Seriously, I think they get it right most of the time. The problem with Lazarus in Bullseye is a bad example but there are very many good examples. Their model of new packages into Sid, then testing and then after an indomitable wait, stable, is really the best you can hope for.

In practice, that's not what appears to happen. Some developers- and I'd highlight Carsten Schoenert who among other things maintains Thunderbird and KiCAD- get a surprising number of changes committed to "stable"... changes with far more effects and far fewer benefits than the current Lazarus version issue.

This for Thunderbird:

2022  4
2021 41
2020 55
2019 28
2018 21
2017 22


And while a few are labelled as CVEs, most are just upstream changes which he's managing to get propagated immediately.

MarkMLl
« Last Edit: January 23, 2022, 10:02:55 am by MarkMLl »
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: A (Debian) Quality Proposal
« Reply #39 on: January 23, 2022, 02:02:40 pm »
Quote
> WRT the hardening issue, ....
Well, Pascaldragon wants to keep it visible, though IMHO an override (so that it is still visible but no longer counted) is better.
As a problem for FPC, Hardening is more of an issue on PPC64el IMHO, being a server platform hardening is important. On Intel few user apps will be statically linked and even if they are, they can be forced not to be. No such option with PPC64el.
For my app in Debian I have just turned Hardening off for PPC64el and they accepted that. But no one is likely to be using it on PPC64el anyway !

x86_64 and Aarch64 are valid server platforms as well (especially the former) and right now static PIE binaries by FPC have problems on all three platforms.

dbannon

  • Hero Member
  • *****
  • Posts: 2786
    • tomboy-ng, a rewrite of the classic Tomboy
Re: A (Debian) Quality Proposal
« Reply #40 on: January 24, 2022, 01:08:48 am »
...
On Intel few user apps will be statically linked and even if they are, they can be forced not to be. No such option with PPC64el.

x86_64 and Aarch64 are valid server platforms as well (especially the former) and right now static PIE binaries by FPC have problems on all three platforms.
[/quote]

You may have missed my point there PascalDragon, on x86_64 and Aarch64 it is possible to to force what would otherwise be a static binary to become a dynamic one and therefore can be hardened. On PPC64el that is not the case.

I'm not saying its not worthwhile fixing the whole issue, and every other issue for that matter. But in the real world, limited resources require us to make priority decisions. I am suggesting that maybe the PPC64el is more of a priority. But if you disagree, thats fine, I respect your decision.

A disclaimer, I do not own any PPC64el hardware, and while once a big user of it, I have not had access to any PPC64el hardware for several years. (and if any past employer wants to offer me such access, No Thanks). So I have no personal interest in PPC64el, my only interest is, as throughout this thread, the quality of FPC.

Davo

Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

 

TinyPortal © 2005-2018