On 2024-03-27, at 10:48:45 +0100, Dr. Burkard Lutz wrote: > Am Dienstag, dem 26.03.2024 um 17:03 +0000 schrieb Jeremy Sowden: > > [...] > > > > The following should suffice: > > > > export DH_VERBOSE = 1 > > export DEB_BUILD_MAINT_OPTIONS = hardening=+all > > export DEB_LDFLAGS_MAINT_APPEND = -lstdc++fs > > > > %: > > dh $@ --with autoreconf > > > > So, this is exactly what I had initially. > > > Running the build one can see: > > > > g++ [...] -D_FORTIFY_SOURCE=2 [...] > > > > so the right argument is being passed to the compiler. > > There is a list > > of the functions that are fortified here: > > > > > > https://www.gnu.org/software/libc/manual/html_node/Source-Fortification.html > > > > Does the software use any of these? If not, this is a false > > positive. > > > > J. > > Galvani only uses "open" for file operations and "read" to read from > usb devices. > > I'm a bit confused now. The output of "blhc galvani_0.34-1_amd64.build" > is empty, but "hardening-check -vR /usr/bin/galvani" gives: > ------------------------------------ > /usr/bin/galvani: > Position Independent Executable: yes > Stack protected: yes > Fortify Source functions: no, only unprotected functions found! > unprotected: read > unprotected: memcpy > unprotected: readlink > unprotected: vsnprintf > unprotected: memset > unprotected: memmove > unprotected: realpath > unprotected: getcwd > Read-only relocations: yes > Immediate binding: yes > Stack clash protection: unknown, no -fstack-clash-protection > instructions found > Control flow integrity: no, not found! > -------------------------------------- > followed by a long list.
I've take a closer look and I don't think you have anything to worry
about. Lintian's complaint relates to five unfortified function symbols
in the galvani binary:
getcwd
read
vsnprintf
realpath
readlink
hardening-check(1) lists an additional three. Of the eight, the galvani
source itself only includes one of them: read(2). The other are
presumably being pulled in via inline functions or templates from header
files or similar mechanisms. Furthermore, the hardening-check(1) man-
page explains that:
When an executable was built such that the fortified versions of the
glibc functions are not useful (e.g. use is verified as safe at
compile time, or use cannot be verified at runtime), this check will
lead to false alarms.
There is one read(2) call (in mess.cxx):
std::string Multimeter::readfrom_dmm ()
{
std::string mwert, extra_str;
std::string error_str;
char buffer[1024];
std::string poll;
if (scpi)
{
dmm_polling = true;
poll = "MEAS?";
}
else poll = "D";
if (usb)
{
if (dmm_polling) writeto_dmm (poll);
int result = read(usb_port, buffer, 1024);
and it is straightforward for the compiler to verify that it will not
overrun the buffer.
I believe your original rules file was fine. The correct hardening
flags were being passed. The fact that there were unfortified function
symbols in the resulting binary was down to the tool-chain and not
anything you were doing wrong.
J.
signature.asc
Description: PGP signature
