linux-kernel - RE: [PATCH v5 18/18] Documentation: ACPI for ARM64

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 6 Jan 2015 14:37:58 -0000
From:	"Charles Garcia-Tobin" <charles.garcia-tobin@....com>
To:	"Catalin Marinas" <Catalin.Marinas@....com>,
	"Arnd Bergmann" <arnd@...db.de>
Cc:	<linux-arm-kernel@...ts.infradead.org>, <hanjun.guo@...aro.org>,
	"Mark Rutland" <Mark.Rutland@....com>,
	<linaro-acpi@...ts.linaro.org>,
	"Will Deacon" <Will.Deacon@....com>,
	"Lv Zheng" <lv.zheng@...el.com>, "Rob Herring" <robh@...nel.org>,
	"Lorenzo Pieralisi" <Lorenzo.Pieralisi@....com>,
	"Al Stone" <al.stone@...aro.org>,
	"Daniel Lezcano" <daniel.lezcano@...aro.org>,
	"Robert Moore" <robert.moore@...el.com>,
	<linux-acpi@...r.kernel.org>, <jcm@...hat.com>,
	<grant.likely@...aro.org>, "Robert Richter" <rric@...nel.org>,
	"Jason Cooper" <jason@...edaemon.net>,
	"Marc Zyngier" <Marc.Zyngier@....com>,
	"Liviu Dudau" <Liviu.Dudau@....com>,
	"Mark Brown" <broonie@...nel.org>,
	"Bjorn Helgaas" <bhelgaas@...gle.com>, <graeme.gregory@...aro.org>,
	<Kangkang.Shen@...wei.com>, "Randy Dunlap" <rdunlap@...radead.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	<linux-kernel@...r.kernel.org>,
	"Sudeep Holla" <Sudeep.Holla@....com>,
	"Olof Johansson" <olof@...om.net>
Subject: RE: [PATCH v5 18/18] Documentation: ACPI for ARM64



> -----Original Message-----
> From: Catalin Marinas [mailto:catalin.marinas@....com]
> Sent: 06 January 2015 14:17
> To: Arnd Bergmann
> Cc: linux-arm-kernel@...ts.infradead.org; hanjun.guo@...aro.org; Mark
> Rutland; linaro-acpi@...ts.linaro.org; Will Deacon; Lv Zheng; Rob
> Herring; Lorenzo Pieralisi; Al Stone; Daniel Lezcano; Robert Moore;
> linux-acpi@...r.kernel.org; jcm@...hat.com; grant.likely@...aro.org;
> Charles Garcia-Tobin; Robert Richter; Jason Cooper; Marc Zyngier; Liviu
> Dudau; Mark Brown; Bjorn Helgaas; graeme.gregory@...aro.org;
> Kangkang.Shen@...wei.com; Randy Dunlap; Rafael J. Wysocki; linux-
> kernel@...r.kernel.org; Sudeep Holla; Olof Johansson
> Subject: Re: [PATCH v5 18/18] Documentation: ACPI for ARM64
> 
> On Tue, Jan 06, 2015 at 02:05:12PM +0000, Arnd Bergmann wrote:
> > On Tuesday 06 January 2015 11:29:29 Catalin Marinas wrote:
> > > > >> We will work on this both on ASWG and linux ACPI driver side,
> as Dong
> > > > >> and Charles pointed out, _OSI things can be solved in ACPI
> spec, when
> > > > >> that is done, we can modify the kernel driver to fix the
> problems above.
> > > > >
> > > > > Which driver?
> > > >
> > > > the ACPICA core driver as you suggested, sorry for the confusion.
> > > >
> > > > > What about ACPI_OS_NAME? Would you suggest it is fine to report
> > > > > "Microsoft Windows NT" on an ARM system? That _OS_ not _OSI.
> > > >
> > > > No, not at all. I prefer "Linux"
> > > > In include/acpi/acconfig.h, when ACPI_OS_NAME defined, it says:
> > > > "OS name, used for the _OS object.  The _OS object is essentially
> > > > obsolete,..."
> > > > for some legacy reasons, we needed  "Microsoft Windows NT", but
> ACPI
> > > > for ARM64 on linux is totally new, I think we can change it to
> > > > "Linux" when CONFIG_ARM64 as you suggested.
> > >
> > > We could ignore this change for now if we don't expect the _OS
> object to
> > > be used at all. But do we have any other way to check the AML code
> for
> > > this? Would FWTS catch such obsolete cases?
> >
> > How about just leaving it out? It's clearly not used for anything
> > good, so I don't see the point in passing either Linux or "Microsoft
> > Windows NT" here.
> 
> Do you mean defining it to NULL (so it ends up as NULL in
> acpi_gbl_pre_defined_names) or removing "_OS_" entirely from that
> array?
> I really can't tell what the implications are.

To me, given that we don't want to use it in ARM64, it would make sense to
have some method to configurably:
0. Leave as is
1. Warn for usage
2. Panic
With a configurability method that allows FWTS to make use of it, and
therefore catch usages of the method.

Cheers

Charles


> 
> --
> Catalin



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/